The Hidden Cost Of Bugs

As a business owner, you see software bugs in 3 forms.

  • Bug List
  • Customer Reports/Complaints
  • Fires

Bug list

This is the list of bugs that your engineering team keeps around.  It is mostly filled with trivial bugs that your team has decided not to fix.

These bugs here don’t have any apparent costs because your team has decided not to work on them.

They only get addressed during some down time or when a new hire needs to get familiar with the code base.

Customer Reports and Complaints

This is the list of tickets created by your customers reporting (or complaining) about issues with your software.  It also may come in the form of your call center being peppered with issues about the software.

These bugs range from minor to pretty serious.

These bugs are irksome because they can cost you in several ways

  • Customer Satisfaction
  • Customer Service
  • Fix

Customers are upset or at least dissatisfied which is why they are calling you in the first place.  Then you have to pay for the support staff to take these calls.  Then you have to pay for your engineering team to fix the bug.

True, many complaints can be minor, but every call or complaint could be the canary in the coal mine.  Which leads to the last bug.


The worst bug to see.  This is when the software product has failed terribly and it’s ‘All hands on deck time’.  Your entire team is scrambling to figure out how to put out the bug, doing whatever they have to do until the fire is out.

Fires are expensive.

As a business owner, you immediately see the costs

  • Loss Of Revenue
  • Loss Of Customers
  • Loss of Reputation
  • Loss of Morale
  • Repair Costs

Fires are costly and painful.

Most business owners understand these costs and have a simple system:

Prevent fires, limit customer complaints, and ignore minor bugs.

But these bugs have costs that most companies are unaware.

If these companies understood the true costs, they would actively try to prevent bugs.

The Hidden Costs Of Bugs


This may seem like a no duh statement.  BUT many companies act as though the bugs they discover cost them nothing.  That is FALSE.  EVERY bug cost the company money, because the company PAID to have every bug made.

When the software was being made, the bug was being made too.  Thus, that bug ALREADY cost you money.

And if you decide to fix the bug, it leads to the next cost.

#2. You are paying to FIX the bug!

You have to pay for the labor to fix the problem. Granted, this cost is obvious.  BUT what isn’t obvious to many companies is that they can be paying WAY MORE than necessary to fix the bug.

The bug fixing process generally goes like this: engineer finds root cause of bug, engineer fixes root cause, test verifies fix works, IT/Operations deploys updated software.

What is MISSING from this process is that this process can repeat itself SEVERAL times for just one bug. For example, the engineer fixes the root cause BUT also creates one or more bugs.

Test COULD catch those bugs and then give it back to engineer to fix OR test could MISS these bugs and software gets deployed where CUSTOMER finds the new bug and the process repeats itself all over again.

Many companies don’t have a tight bug fixing process and as a result they can UNKNOWINGLY go through this debug cycle several times for a single bug.  So they pay to fix a bug several times when they should have a process that forces them to do it right the first time.

Which leads to the last cost.

#3. Opportunity Cost

An engineer is most valuable when he or she is making things that will make you money NOT fixing things that ALREADY make you money.

Engineering is an investment that can pay back huge dividends.

An engineer could whip out a tool in 1 hr that saves your operations team or your sales team HUNDREDS of HOURS a YEAR.

1 engineering month could dramatically increase your revenue.

Engineering hours should be spent creating your company’s future.

Every hour they have to spend FIXING something is an hour of your company’s future thrown away.

THESE are the REAL costs of the bugs that your team is working on every single day.


So how do you fix this?  How do you save yourself these costs?


BUT given the difficulty of that, we should strive to catch bugs as SOON as they occur.

The sooner a bug is caught, the cheaper it is to fix.

For example, say I’m building a house and I dig a sewer drain incorrectly. If I catch it as soon as I do it, it’s easy to fix: An hour of time to dig the drain again.  But if I don’t catch it and I continue building the house, when the issue is finally caught (hopefully by the home inspector) it is WAY more expensive to fix.

Here are 3 simple things you could do to improve your software development process to catch bugs as SOON as they occur.

How To Improve Your Software Development Process

#1. Requirements Review

This can be tedious but it is SOO crucial.  Every error in requirements that you catch will save HUNDREDS of hours of work.  Think of it this way.  There once was a construction company that was building a $100 million building.  Towards the end of the project, the elevator people came to install the elevators.  That’s when everyone realized they hadn’t built an elevator bank.

Or you can be like a company I worked at, where they spent 18 MONTHS building a product only to find out a month before the contract ended that the requirements were ALL WRONG.  They had to spend another 5 months cobbling together a different product.

Review your requirements early and often.  It will save you money.

#2. Code Reviews

This is another task many companies ignore.  Of the companies I’ve worked for, HALF required code reviews.  And only 1 company even had a process in place to make sure the code review occurred and was effective.

Code reviews are essential because it prevents sloppy programming.  Not saying engineers are sloppy BUT there is an extra level of focus when I know that my colleagues, the people I respect, will be looking at my work and judging it.

It helps to catch many bugs before they get passed on.

There is the ADDED benefit that they improve your engineering department.  Typically, your weakest engineers will get better faster because the code reviews serve as a form of mentoring.

#3. Automated Unit Tests

This one is a KILLER.  It pays BIG dividends, ESPECIALLY the larger and older your code base is.

With long term products that have large code bases and lots of legacy, many hands touch the code base.  Eventually, the original team isn’t working on the software anymore and they take with them CRUCIAL design decisions and requirements that were made.  Then new engineers come in, make changes that seem to work, but then wind up breaking things much later.  It’s not the fault of the new engineers, they didn’t know.

Automated tests serve as a guardrail to make sure you aren’t introducing new bugs as you make fixes and improvements to the product.

They are great because they find bugs quickly (within seconds) and are a one-time down payment.  You don’t have to continuously pay your testing team to manually perform these regression tests.

Fedex in Orlando deployed this a few years ago.  They used to get fires in the middle of the night often…but after a year of implementing this, midnight fires were a thing of the past.

Now I hear what you are saying, this all sounds well and good but I do not have the resources and time to get this done.



A consultant can help you develop bullet proof unit tests OR help you improve your process to quickly find and cheaply repair bugs.

By not addressing these issues, you are robbing Peter to pay Paul.  In the short term you can ignore the costs of bugs, but you are costing your company’s long term viability.

Think about how awesome your company could be if your engineering team was doing what it was supposed to do, which is experimenting and inventing your future.

It is now that I’ll put in my plug.

I am a software consultant and I can help you save and make money.


Contact me for a 15 minute consultation.  15 minutes could make you thousands.