“Why do you have brakes in a car? Because then you can drive faster. [1]” I like this quote, and I find it very relevant to modern software engineering. Teams that know when and how to use the brakes can drive a project fast and still arrive safe and sound at the final destination. But some agile teams are speeding; driving too fast, reluctant to actually use the brakes, and so they drive a project off the road. For example, sometimes you see teams being so much focused on implementing customer visible features that they forget about the importance of a sound and solid internal infrastructure. It seems like the old “nah, we are in a hurry, let’s write tests and documentation later” (which nobody did of course) has now been replaced with “nah, we are in a hurry, let’s do proper design and architecture later” (and this will of course never happen either).

Agile methodologies encourages you to do things in small steps, often in cycles that can be measured in seconds or minutes. It does not really matter if you do ‘think/change/test’ or ‘add test/change/refactor’, sometimes you will meet challenges that require many hours or days or even weeks to do properly. Just as we in the old days could spend months on a Big Design Up Front (BDUF) before starting to code, we must now be prepared to pause once in a while and spend some time thinking. For example, suppose you are to implement a feature where you need to store some values for later retrieval. You realize that you need some kind of persistence mechanism - and it is obvious that a big chunk of internal infrastructure is missing. This is a time where you need to slow down and make sure that you do this properly. Being agile should not be used as an excuse for just mocking up some poorly designed ad-hoc persistance mechanism.

If you do not slow down when required you will end up with bad design and architectural rot. Soon developers will start to complain about: “it is hard to find stuff”, “it is hard to add stuff”. Despite everybody working very hard, the real progress of the project is next to nothing. The project is like a car stuck in the mud, now pressing hard on the accellerator pedal is not what you want to do. This is not a time for more hard work, now you need to start thinking. You have wasted a lot of time and effort already, but if you are willing to backtrack a bit you might be able to fix the bad design, improve the architecture and get the project back on track. Not slowing down when required will cost you a lot in terms of time and effort, but also in frustration and lost confidence from developers and management. Actually, just like when driving a car, the penalty of driving too fast is so high that (most of us) always prefer to have a large security buffer. If you are eager to successfully complete one project after another, then behave and drive sensible. But of course, in software engineering there are no real cops watching you, so if you can see a very long open stretch, then go for it…

[1] I first heard this quote from Kevlin Henney at ACCU 2008.