Passion for software development

Find Bugs Fast


Is it important to find bugs early in the development process? I guess that most of you would answer yes on that question. But how important is it really? In this post I will try to explain to you how important that could be.

I have identified a few points in time where it's possible to find bugs in the development cycle. Let’s take it from the end and it’s also the worst scenario and that is that the customer finds the bug. One step better would be that we find the bug in an internal manual test. One step better than that would be that a automated test during the nightly build found the bug. And at last one step earlier then that would be that the developer finds the bug with help of the compiler or automated test on the developers machine.

Depending on when the bug is found it will have an impact on how much time it will take to correct the error and how long time it will take before we have working software with this correction. So what I want to illustrate for you clearly is how big the correction time impact will be depending on when you find the bug. The big win here will be that if you are able to find the bug early then you need to spend less time in fixing the problem and you can put that time on building new things instead of fixing problems. This will give you higher speed in your development.

Bug correction example

To illustrate my points here I will use a fictive company with a fictive development process. Let’s call this company x-corp. You might think that all software companies are like Facebook, Netflix and others; these are the companies that can put new code into production hourly. Facebook for instance have the development slogan “move fast and break things”, they can do that because they can fix the problems fast also. But most companies are much slower of releasing new code.

The x-corp, company is in the faster half of companies when it comes to build, test and release process and on average it can do a new release every 24 hours. When I say that the x-corp is in the faster half I talk about the standards in the industry in the year 2015.

Change the code experiment

In this x-corp experiment we will look at one bug and find out what consequence it has on the time it takes to correct and how long time it takes before the customer has the working software, depending on when we find out that the bug exist.

My hypothesis is that if we find the bug as soon as possible then we need to spend less time on fixing it. If we spend less time on fixing the bug we have more time to do new functionality to our product.

The info graphic that is interactive (click on the dots to see impact on when the bug was found) shows times that are rough estimates on how long time things take. As you know it can vary a lot on how long time it takes correct a bug, so a rough estimate is the best I can give you.

The infographic also show how much of the code the developer forgets the longer time it takes from when the code was updated until the bug was found. It also shows you how many people that needs to be involved in the correction process depending on when the bug was found. In the bottom of the infographic you also see a Value Stream Map that was used to calculate how much time was spent on correcting the bug and how long time it took before the customer had the working software.


The first state (No Bug) of the infographic shows the times and impact of the software change when no bug was introduced in the software. And then when you look at the worst case (Customer Found Bug) when a bug was introduced when the software was changed all times and impacts doubled compared to when no bug was introduced. For instance the time spent on the software change goes from 5.2 hours to 12.2 hours. So, it’s almost one working day wasted on the new bug introduced in the system. x-corp could have spent that time on creating a new features instead on correcting that bug. So it’s obvious that it’s important to find bugs as early as possible, since then you don’t need to spend time on correcting bugs and instead ship new features!

Interesting Links: