The Cost of Fixing Bugs Late

Have you ever been in a situation where you’ve written a piece of code and it’s almost there but there are a few niggling issues which “can wait for V2?”. Have you ever wished, maybe months later that you’d gone back and resolved them at the time? You’re not alone!

More and more developers and managers are beginning to realise the true cost of fixing bugs late, not only on their sanity but on the company’s time and money.

Let’s say for the sake of argument that you’ve finished a piece of code except for a few edge cases. You’re under a lot of time pressure so you decide it’s of a high enough quality and you push it through to QA. The cost to the business of fixing that issue actually increases dramatically the longer it’s left.

Let’s look at a few scenarios:

You fix the issue immediatly

• Fix time – 30 minutes

You send to QA and it’s rejected there

• Fix time – 30 minutes
• Build time – 2 hours
• QA deployment time – 1 hour
• QA signoff testing – 24 hours
• Fix time – 30 minutes

QA passes as an “edge case” but the customer disagrees

• Fix time – 30 minutes
• Build time – 2 hours
• QA deployment time – 1 hour
• QA signoff testing – 24 hours
• Deploy to UAT – 3 hours
• Customer UAT – 1 week

Missed in UAT but discovered as a significant issue in Live

• Fix time – 30 minutes
• Build time – 2 hours
• QA deployment time – 1 hour
• QA signoff testing – 24 hours
• Deploy to UAT – 3 hours
• Customer UAT – 1 week
• Customer live deploy – 3 hours

As you can see, even with these rough estimates the time it takes to resolve the customer’s issue increases dramatically the longer it’s left. Not only that but the cost of time to the business of paying staff to run extra QA cycles or rounds of UAT spirals out of control. We haven’t even considered the final case where it goes to the bug queue to die and a completely different developer has to learn the feature and resolve the problem.

The graph is actually a very common shape*.

I’m a big fan of practicality, no software is going to be perfect and it’s unrealistic to expect that you’re going to find and fix each and every issue before shipping to a customer.

However, hopefully this has made you stop and think and has provided a strong argument for making that extra 30 minutes to resolve the issue before it causes a real headache for the business!

*Thanks to fooplot.com for the graphing software.