The Hidden Cost

(…) Of course, there is the standard argument that the later a bug is fixed, the more expensive it is to fix. I’m going to assume that everyone has heard that argument before, and more-or-less agrees with it. I want to talk about something a little more insidious. When you fix a bug not only affects the cost of fixing it, but also the way you fix it.

As development work continues in the presence of a known bug, new dependencies on the code where the bug lives are likely to be added. Sometimes these dependencies will be on bug itself. Often, this happens without the developers realizing it. In general, as a piece of code acquires dependencies, it becomes riskier to change. I think this is even more true of bug-ridden code.

So, the longer you wait before fixing the bug, the more risk is introduced in fixing it. When the risk of fixing a bug increases, the reaction of most developers is to stick with the potential fix that appears least risky (even if there is a ‘better’ alternative).

(…)

Now we’re getting down to the point. When you put off a bug fix, you are going to feel pressure to go with the (perceived) less risky solution later (the quick hack that fixes the bug but reduces code health). And lets face it, most of us are not good with dealing with pressure. If we were, we would probably insist on fixing the bug now rather than later in the first place.

So not only are you going to take longer to fix the bug later, you’re going to take on technical debt, and all the pain and suffering (and reduced velocity) that technical debt entails.

Author:  Ryan Cooper for the full article on the on-agile blog go to:

http://on-agile.blogspot.com/2006/12/hidden-cost-of-delaying-bug-fixes.html

Technical debt

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

Ward Cunningham (1992)

More on technical debt from Steve McConnell: http://is.gd/7BhKf

Quality Time is a Futurice awareness campaign to improve knowledge related to testing. Follow Quality Time at http://blog.futurice.com or on any Futurice rest room.