back to BLOG

The Cost of Finding Bugs Later in the SDLC

Boost software quality and resilience by moving defect detection as early in the workflow as possible.

January 5, 2023
Tamas Cser

Elevate Your Testing Career to a New Level with a Free, Self-Paced Functionize Intelligent Certification

Learn more
Boost software quality and resilience by moving defect detection as early in the workflow as possible.
The saying "prevention is better than cure" applies to defects in the software development life cycle in the same way that it applies to illnesses in the medical field.

The cost of identifying and correcting defects in software grows significantly as time goes on in the software development process. Fixing bugs that are discovered after the software has been released can be extremely expensive and risky, generally costing significantly more than fixing them at earlier stages.  Making changes to the code to fix a bug can also impact the functionality of the application, which may require additional changes to be made, increasing the cost, time, and effort required.

The graph below, provided by the National Institute of Standards and Technology (NIST), illustrates how the effort required to identify and fix defects increases as software progresses through the five broad phases of development.

Cost of Defects - in Software development life cycle

According to the Systems Sciences Institute at IBM, the cost to fix a bug found during implementation is about six times higher than one identified during design. The cost to fix an error found after product release is then four to five times as much as one uncovered during design, and up to 100 times more than one identified during the maintenance phase. In other words, the cost of a bug grows exponentially as the software progresses through the SDLC.

IBM System Science Institute Relative Cost of Fixing Defects
IBM System Science Institute Relative Cost of Fixing Defects

Why Costs Increase Later in Each Development Phase

It is much easier for developers to detect problems in their code when they are actively working on it, as the code is still fresh in their minds and it is easier to fix even complex issues. As time passes and the code moves to later stages of development, it becomes more challenging for developers to remember all the details and locate issues before they can be fixed. Using an automated system like continuous quality integration to identify issues in the code while developers are still writing it can make it easier for them to make the necessary corrections, as the code is still fresh in their minds.

During the testing phase, it can be time-consuming to reproduce defects on a developer's local environment. While it is relatively easy to identify issues that are clearly broken or do not meet requirements, it is much more challenging to uncover deeper defects such as memory leaks or race conditions. Unfortunately, these types of issues often do not become apparent until the software is in the production phase, if they are not detected earlier in the coding phase.

When software has been released and is being used in the field, not only is it difficult to locate defects, but it is also risky to try to fix them. In addition to avoiding negative impacts on live users, it is essential to maintain the availability of the service, as this is critical for business. The cost of fixing defects at this stage can be as much as 30 times higher than if they were addressed earlier in the development process, due to the additional challenges and risks involved.

Detect Early, Detect Often

The arguments above withstanding, it is valuable to implement processes which enable developers to detect early, detect often. Essentially, the development workflow should ensure that defects can be detected as early as possible — preferably during the code is being written by the developer or is in code-review stage before being merged to the main development branch.

Processes like continuous integration help ensure that changes to the code are small and manageable, so it's easier to detect issues. Tracking code coverage and ensuring that a certain threshold is helpful, and facilitating iterations on the code to fix these issues. Implementing static analysis can help keep code clean by automatically detecting hundreds of bug risks, anti-patterns, security vulnerabilities, and so on.

In essence, processes and conventions should be designed around moving defect detection as early in the workflow and as closer to the developer's coding environment as possible. This way, the same compounding effects which inflate the negative impacts of late defect detection work in favor of increasing software quality and resilience.