Speed Kills

We are a generation of software developers who have been taught it is better to write code quickly than slowly. We pride ourselves on how quickly we can get something to work. We expect to be evaluated based on this speed. We believe that speed is the mark of the professional.

Baloney!

Speed is the prime destroyer of software systems. In our rush to get something to execute we make mess upon mess. We push and shove the code around in a frenzied effort to make something work. And then, once we achieve the desired behavior, we consider ourselves to be done, and move on to the next urgent task.

Of course we all realize that this is self-destructive behavior. We know that the more we rush the deeper the messes become, and the slower and slower we will go. We know that the only way to keep development going fast is to work carefully, deliberately, and slowly. We know that if we do this, we will keep our systems clean and well structured. We know that clean and well structured systems are easy to change. We know this. Yet we find it difficult to act on this knowledge.

The traditional productivity curve for software projects is a sigmoid. It starts very high, and remains high for the first few months. This is the honeymoon period when the team is cranking. They get lots of good work done, and they get it done quickly. But then the messes begin to build. Those messes slow us down. The productivity curve enters a steep and sudden decline. A few months later productivity has bottomed out and asymptotically approaches zero. This is the phase of the project where it takes forever to do even the simplest thing. This is the phase of the project in which the smallest possible estimate is 3 weeks or more.

As productivity slows to a near halt, the business responds in the only way it can - it adds more people to the project in the forlorn hope of increasing productivity. But these new people, eager to please their employers and peers, continue to rush, thereby adding even more corruption to the existing steaming pile. Productivity continues to decline as the sigmoid approaches zero at the limit.

The solution to this nearly ubiquitous problem is to act upon what we already know. That speed kills projects. Slow down. Do a good job. Keep the code clean. Write unit tests. Write acceptance tests. And watch how fast you go!

Speed Kills Projects.

---

!commentForm

Append your comment below

• Sep 9, 2004, Alan Wostenberg: Uncle Bob, I read in Mary’s _lean development book_ we can have it all – quicker, better, cheaper. Which expert shall I trust? –Confused in Omaha.
• In this case you can trust us both. By being deliberate, careful, and by focusing on quality, you’ll work quicker, better, and cheaper. – UB
• Sep 10, 2004, Corey: I agree totally. One thing I fight against with other developers is the concept that “fast” is a measure of development, rather than delivery. I’ve been trying to convince people that TDD doesn’t slow you down significantly, because it dramatically cuts down on the amount of end-phase QA time. Slowly, but surely, I’m convincing people. Especially when they are willing to dive head-first, try TDD (or what I like to call, Test Please, which means that the tests need not drive the design, but you should have executable unit tests for everything), then see how they feel after a month. After all, we are willing to try a new coffee or shampoo for a month, why not a new development strategy.
• Oct 31, 2004, Jason Gorman: If we define “speed” as the rate at which we make progress, then I guess it depends on how we measure progress - and therefore how we define our goals. Developers who think that speed relates to the rate at which we write code are perhaps working towards the wrong goals?
• Feb 8, 2005, Roger Glover: I am reminded of the passage in John Brunner's excellent novel The Shockwave Rider, in which protagonist Nicky Halflinger discovers the key insight of his journey. Basically he discovers that managing large systems is like orbital mechanics; speeding things up actually slows you down, while slowing down and taking your time gets you there faster. See you later, accelerator!