Many software development organizations believe that there’s a tradeoff between quality and speed; that is, in order to improve quality, they believe that you have to slow down. Conversely, speeding up, such organizations believe, necessitates compromising quality (all other things being equal). This is just not true.
In reading Gregor Hohpe’s fantastic book The Software Architect Elevator, he suggests that we should consider quality and speed as separate axes on a two-dimensional plane. The false perception that many organizations believe, if we visualize it in Hohpe’s way, is that there’s a linear tradeoff. More quality means less speed:
The trouble with this perception is that such organizations have such pressure to deliver that they believe everything that can be done to improve speed should be done. This pressure to ship trumps all. The perception that increased quality harms speed incentivizes organizations to keep as close to the unacceptable quality zone as possible. There’s no apparent reason to invest in more quality, because they just need to be slow enough to keep quality above an acceptable level. Any slower would be wasteful.
There are two problems with this perception. First, immature organizations have a distorted view of quality. This typically appears as the belief that the absence of bugs is the presence of quality. Therefore, measuring the quality of the software is done by testing, and improving the quality of the software is done by bugfixing. The second problem is that such organizations usually under-invest in automation. Humans at immature organizations do repetitive, tedious, rote jobs that would be far more efficiently done by computers.
What’s true of mature organizations; however, is that quality enables speed. Highly effective software development organizations build their culture around quality. Activities like automation, design improvement, retrospectives, education, transparency, and CQI reshape the relationship between quality and speed. By investing in quality, it makes it possible to go even faster:
Notice the left side of the graph. As organizations mature, their concept of “maximum quality” becomes greater and greater. Also notice how the rightmost parts of the graph become almost vertical: these organizations recognize that “go faster” causes drastic drops in quality.
Quality is multi-faceted. Immature organizations use bugs as an inverse proxy for quality, with lackluster results. Mature organizations look for opportunities to introduce and encourage internal quality; that is, the kind of quality that isn’t visible to end users. If the quality is poor enough that it has end-user impact (i.e. bugs), that is the slowest and most costly kind of quality to repair. By emphasizing internal quality, costly problems are prevented early while they’re still inexpensive (to see some of the industry research regarding internal quality and its relationship to speed, check out Accelerate). By emphasizing quality investment, new insights yield serendipitous combinations of both quality and speed.
Truly, the only way to go fast is to go well.
