Yesterday I contended that the idea that a bug costs 1000x more to fix in production verses at the design stage is a bit of an odd argument for any teams doing agile software development, for the simple reason that the various “stages” of software development are intermingled, and done in a tight loop.

But how can we know if we’re working in such a way? I’m not aware of a ton of data on the topic, but there is some, and as I find more, of course I’ll be happy to share it.

The first thing I found, once again from the often-cited book Accelerate:

We alread know that continuous delivery predicts lower change fail rates. However, we also tested several additional proxy variables for quality [and] our analysis found that all measures were correlated with software delivery performance. However, the strongest correlation was seen in the percentage of time spent on rework or unplanned work, responding to urgent audit documentation requests, and so forth.

High performers [in continuous delivery] reported spending 49% of their time on new work and 21% on unplanned work or rework. In contrast, low performers spend 38% of their time on new work and 27% on unplanned work or rework.

So, a healthy continuous delivery practice correlates to aproximately 28% less time spent on unplanned work or rework, of which bug fixing is part.

What does Accelerate count as “continuous delivery”? Well, that deserves a lot more attention than I can provide at the end of this message, but here’s a quick check list of some of the key charactaristics. Which of these are you doing?

• Version control (such as git)
• Test automation (reliable tests that automatically inform you when something breaks)
• Trunk-based development
• Then obviously, implementing continuous delivery

For anyone interested, I talk in more detail about how to actually implement continuous delivery (and the related concept of continuous deployment) in my free email bootcamp on the topic: The Lean CD Bootcamp.