I recently saw an email from a colleague who mentioned that they did not have time to properly resolve a technical issue because they needed to hurry to get their code ready for testing. At the time, I was reading Stephen Hunter's novel The 47th Samurai
How do you do something quickly? How do you learn to go fast? The naive approach is to rush - try to do things as quickly as possible. But what prevents us from going at maximum speed? Inefficiencies in our actions. Mistakes in our execution. Rushing simply makes this worse. Only through deliberate practice can you learn to eliminate these disruptions and become smooth. Only the trained professional can be fast.
In the context of I.T. I all too often see people trying to hurry to be ready for testing, typically due to milestone deadlines like the start date of acceptance testing. But if you want to deliver quickly, the key is high quality analysis and coding. Rushing to test only increases the likelihood of defects which will slow you down. Lean theory tells us to build quality into our process in order to eliminate waste. No waste is smooth, and smooth is fast. The untrained will perceive this as going slow. And in the very short-term it is slower to spend time on activities like design discussions, code reviews, and automated testing. But this allows you to deliver faster. Slow is indeed fast, because slow is smooth and smooth is fast.
The more quickly you need to deliver, the more discipline you need to execute cleanly and precisely. In other words, smoother is faster. One of the promised benefits of Agile methods is frequent delivery, but this takes discipline to achieve. I have heard multiple times of development teams using Scrum without any supporting development practices (e.g. those espoused by XP) quickly slowing down after their code base builds up too much technical debt. I have talked to people steeped in traditional waterfall that mistake the minimization of formal ceremony (e.g. official signoffs) and big documents in Agile as undisciplined, rather than seeing that it is a very deliberate elimination of waste to go faster. Agile approaches still have mechanisms like the product backlog and sprint planning / sprint demo meetings in Scrum that provide the disciplined structure necessary to go fast while minimizing the associated overhead.
There is another issue with rushing to test. The overall objective of I.T. development is to deliver functionality to end users to address business goals. Taking shortcuts, rushing to test, and dealing with many defects in testing is likely to delay the date when you can deliver to production. So rushing is foolishly short-sighted. Keeping your sights on the overall objective will help prevent premature rushing.
So let us strive to be trained professionals who are careful to be disciplined in execution. Because slow is smooth, and smooth is fast.
