The Need For Speed
Posted by Uncle Bob on 12/21/2006
Yesterday was the day we felt the acceleration.
As you may know, we’ve been working on a largish web application to use as a running example in our new Principles, Patterns, and Practices course. The first couple of days of development were typically slow; and we all felt the pressure of getting “too little” done. But we stuck to our disciplines and wrote tests, and kept the code as clean as possible.
Working this way is not easy. We have a deadline that is very real; and there is a lot of money tied to it. So we all feel “the need for speed”. But all of us also know that Brian Marick is right when he says: “When it comes to software, it doesn’t pay to rush.” So we’ve nervously tolerated the pace and continued to practice TDD and continuous refactoring.
On the third day it started to pay off. The structure of our code is clean and simple enough that new features are starting to be able to take advantage of older features. We have enough tests (~90% coverage) to ensure that minor refactorings to facilitate reuse aren’t risky. And so we were able to twist the code a little here, and tweak it a little there, and within a single day triple the functionality of the code.
Let me make this more concrete. We have a set of stories. We’ve estimated those stories with point values. The sum of our velocity on Monday was close to zero. On Tuesday we got 11 points done. On Wednesday we got 26 points done. This acceleration is due to the fact that we were able to take advantage of the similarities in the features and craft the new features into place by making fine adjustments to the existing structure.
I don’t need to tell you that if we’d been practicing cut-and-paste programming we would not have had that option. Instead of a carefully crafted structure that allows new features to be easily melded, we’d have feature silos with much duplicated code and messy tangles.
Comments
Jason Gorman 29 days later:
I couldn’t agree more. I’ve run 3-day workshops where the code written on the first day is really starting to slow developers down by the third day. Managers are always keen to sideline code quality as a “long-term issue” (management-speak for something that will never be dealt with), and refactoring constantly gets pushed back and back until the clean-up required is so huge that nobody dare even mention it in planning meetings. But I know from experience – and so do you! – that it has a profound impact on productivity, even on small projects.
And, since you’re writing the code, and since we know from experience that continuous refactoring helps productivity and saves time, even in the short term, don’t feel you need a permission slip from the project manager to do it. Just do it!
ipad to itunes transfer over 3 years later:
that it has a profound impact on productivity, even on small projects.
And, since you’re writing the code, and since we know from experience that continuous refactoring helps prod
Criminal Records over 4 years later:
I remember the title of this topic the pc game need for speed. But it’s totally different to what I thought.
Tenant Screening over 4 years later:
This acceleration is due to the fact that we were able to take advantage of the similarities in the features and craft the new features into place by making fine adjustments to the existing structure.