I recently heard about a mantra used and repeated many times by legendary mens’ basketball coach, John Wooden. A former basketball player who played for Wooden at UCLA, Andrew Hill, and Wooden himself, wrote a book by the title: Be Quick - But Don't Hurry: Finding Success in the Teachings of a Lifetime. I found it via an email that came to me via the mailing list of philosopher, Brian Johnson. I like Brian because his purpose is helping humans to live optimized lives. Here is Brian’s summary of the book. He prominently cited this quote:
“Be quick—but don’t hurry! is a phrase that every Bruin player heard constantly. Over and over, day after day, Coach would briefly stop practice, and in sharp staccato tones, with just a hint of an Indiana twang, snap out, ‘Be quick—but don’t hurry!’ It was Coach’s mantra. Oftentimes, Coach would crouch down in a defensive stance and move his hands like a lightning-fast magician as he repeated this saying. At times it almost became a joke, but after a while, you began to understand exactly what he meant. Life, like basketball, must be played fast—but never out of control. Coach says, ‘If you hurry, you’re more likely to make mistakes; but if you’re not quick you won’t get things done. It’s like a surgeon who comes upon things that are unexpected. If he isn’t capable of responding quickly he may lose a patient. If an attorney isn’t a quick thinker, he could lose a case.’ It’s hard to argue with that statement.”
—Andrew Hill with John Wooden from Be Quick — But Don’t Hurry
When I read this quote from the book, I think of building a software system. Everything in here applies. Business moves fast and software has to move fast to keep up. Moving quickly is the hallmark of the excellent software shop. Every person who has ever been involved in any software project, though, knows the costs associated with hurry. Cutting corners always results in a mess that needs to be cleaned up. Skipping a test or hacking something together, the cost comes home eventually.
The cost of hurry is so well known among software teams that we’ve invented a term to capture it in a couple words that can be quickly spoken and everyone understands: technical debt. Ward Cunningham coined this term to use metaphor to describe what is happening in software when the quality of the code has deficiencies (not necessarily defects causing incorrect behavior, but deficiencies) in quality that will make future change more difficult. Ward Cunningham explained why he used financial debt to demonstrate the principle of the costs of not refactoring.
Technical debt is about more than some future difficulty. It is the result of either short cuts or an understanding of the problem domain that is lacking in some regard. The first is fine, sometimes, if it is chosen consciously and with a payment plan in place to resolve the debt moving forward. The second is a natural consequence of evolving an understanding while needing to proceed before a complete understanding can be achieved (and a complete understanding is something we approach, probably never actually arriving). Again, without a plan to pay down the debt, servicing the interest on the debt begins to consume significant amounts of resources in moving forward.
Thinking of technical debt and the costs of hurrying make me think of what Ron Jeffries had to say about the #NoEstimates movement. Among many thoughts about why there is virtue in the movement and pointing out what is lacking, he shared this gem:
And estimates are often misused. Estimates are often used as a bludgeon to try to get programmers to work faster. This leads to unhappy programmers and to poor software. No one wins.
This gets to the heart of the problem of estimates. This is why there is a movement. If estimates always were treated as something giving guidance and offering some sort of expectation to the business, they would be what they are: hard to do accurately and only useful in a rough and approximate way, but useful and mostly harmless (Douglas Adams reference intentional). It is this use as a bludgeon, adeptly observed by Ron Jeffries, where there is a reason to push back and to have a movement trying to improve the situation.
Hurry to try to make a rough estimate into an accurate projection – making a date because it was given – Calendar-Driven Development – these are sources of poor quality and difficult maintainability. Rather than thinking that your project doesn’t have time to refactor, you need to consider whether you have time to forgo refactoring.
Matt Wynne shared some measurements he did to determine how much refactoring was going on in the Cucumber core. The results show a heavy emphasis on refactoring. This is evidence that this is not a case of hurrying, but one of being quick with things that need to be done while making sure to take the time to do due diligence in making sure quality is present.
By all means, please be quick. Getting your useful implementation into the hands of your users is why you are doing what you do. It is also in shipping software that you find out where you have met the needs of your users and where you need more attention.
Please, though, don’t hurry. Do what you need to do to have confidence in your deployments. Make sure you have tests in place so that you can refactor with confidence to improve the quality of your model. Automate your integration and deployment so that you don’t have to do things manually that would be better left to machines. Pay attention to your logging so you know what is happening in production. Observe real users using your real system. Without taking the time to do these things, you will spend more time dealing with the deficiency in the long term.
Be quick, but don’t hurry. Thanks for the great advice, Coach Wooden.