- Consulting / Coaching
- Jeff’s Blog
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.
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 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…
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.