The Biggest Cost of Developing Software
Undetected bugs contribute to the biggest hidden costs of development teams. In this article, we'll cover why that is, and how to avoid it.
When developing software there are several costs involved. Some of these costs include:
The cost to design + spec the project
The cost to acquire engineering resources
The cost of infrastructure
The cost of third-party resources
These costs are greatly outweighed by the engineering cost of fixing undetected regressions. To understand why we have to first understand what a regression is. A regression, simply put, is a bug. It's the application functioning in a way that was never intended. An engineer's job is to eliminate these bugs. Doing so is an easy feat when there are few features. But when applications become mature, and features become interdependent, the difficulty of fixing regressions greatly increases.
To make matters worse, if a bug goes undetected, and additional features are built on top, fixing the bug means also fixing the other features built on top. And just when you thought it couldn't get worse, because those features depend on other features, you may have to fix all of those as well.
As an example, let's say to fix 1 bug it takes 1hr of time. If the bug is detected right away, it takes 1hr of time to fix. Simple.
Now let's take another scenario, let's say the same bug isn't discovered for 4 days (32hrs). And in that time the engineers built several features on top of the bug. In addition to fixing the original bug, the engineers also need to fix the other features. Let's say 20% of the features built on top will need to be refactored. That means fixing this regression now takes (20% * 32hr) + 1hr = 7.4hr. That's a 740% increase in cost, all from a single undetected bug.
Test-Driven Development aims to avoid this cost. It does so by reducing the number of unpredictable bugs introduced into the code base. The technique not only reduces the overall cost of development but dramatically improves the predictability of delivery.
All Raidon projects utilize some form of test-driven development. Doing so allows us to create project traction. We can rely more and more on the work of yesterday and build on top of it without worrying about making the project worse.