“code bug,” courtesy Guilherme Tavares. License.
We occasionally hear dramatic stories about defects that killed or cost multi-millions or billions(!) of dollars. Yet these fiascos likely don’t change our programming habits. Maybe we don’t worry since our application isn’t critical enough. Or maybe we’ve learned to accept defects as a necessary evil.
What’s the defect count on your primary system? Chances are good you have hundreds if not thousands of defects. We know that these defects represent some problem, but calculating the true cost they represent is extremely difficult, so we don’t ever bother. Let’s mull over some of the cost increases that defects create.
-
If we choose to fix a defect, we incur the cost of changing the code. We can’t fix the problem without also the cost of finding its cause, an often daunting task that can get worse the longer we wait. (More code to deal with, more convolutions, less mindshare about the original solution, …)
-
Fixing a defect represents increased opportunity costs (time spent not delivering new revenue-producing solutions). Anecdotal evidence (from teams I’ve worked with, associates, and Google-ing about) suggests that a typical team might spend anywhere from 20% of time to 60% or more on rework demanded by fixing defects.
We’d like to think that when we fix a problem, we can move on… but chances are decent that in fixing a problem, we unwittingly created other defects of similarly undetermined cost.
-
We incur a cost to track and discuss all the damn defects and prioritize the order in which they will be corrected. Maybe it’s a small cost, but this overhead is pure waste that adds up.
-
We must pay to “support” the errant behavior in production. How many support folks does your application demand? A customer of mine boasted very few production defects, but they only meant problems that prevented their customer from accomplishing their goals. It turns out that they had a very fat book of workarounds and a support staff of over 40 (for an application that might have demanded maybe 10 folks at any other shop). Extra support folks cost money, and so does their manager, their computers, and so on.
Ahh but we also have support tiers. What’s the cost of stressing out the team and managers in the middle of the night or over weekends with production issues? Many developers look at “being on support rotation” as a given, necessary evil, but its stress toll can be significant. If you burn out your people with off-hours support, the good ones may move on—a potentially devastating cost.
But wait… I mentioned customers, so…
-
How much are we costing our customers? Defects increase our customers’ cost of getting their jobs done, which similarly increases their opportunity costs. Maybe we should care, because…
-
What’s the cost of losing a customer? Or all of them? You’ll never know how many customers stopped using your product due to its too-many or too-severe defects, because “people don’t tell you when they stop trusting you.” (Gerald M. Weinberg, The Secrets of Consulting, Dorset House Publishing, 1986)
We know these things all cost *something*, but we will probably never truly know how much.
Defects aren’t our only quality-related cost sink. I’ll discuss the cost of poorly constructed code later.
“It means doing exactly what you said you were going to do—that’s really the definition of quality. That way you save the expenses of doing things over again, and you don’t disappoint anybody.” – Philip Crosby as quoted in Industry Week, “Philip Crosby: Quality is Still Free,” by Tim Stevens, June 19, 1995.
