1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

How Code Reviews Reduce SDLC Costs

Published by Mike Solinap
on January 10, 2012

Bugs can be introduced anywhere in the software development lifecycle, from the early stages (requirements gathering etc) right up to the final shipping of the project. The most expensive types of bugs to fix are those introduced earliest and fixed latest. For example, a design error that needs to be fixed once the product is live in the field, is very expensive to fix. Whereas a coding error found and fixed the day after it was made, is the cheapest to fix.

Since large amounts of software development is commercial and needs to demonstrate profit, reducing costs and increasing margins is essential for success. However, even open source projects or the hobbyist writing code in his/her spare time can benefit from reducing the “cost” (meaning effort and time) of fixing bugs.

I was once told by a senior engineer that reading the comments written by a developer can often shed light on what the coder was trying to do rather than what they achieved. The key to his advice is that when a programmer needs to explain their design or implementation, it forces them to re-think and quantify their work. The very act of starting design and code reviews actually forces engineers to re-evaluate their work and in doing so can reveal bugs and flaws previously hidden.

Two heads are better than one

Applied to software engineering this means that by employing a system to peer check and review software design and implementation, the resulting work will have been verified and validated by at least two people, reducing errors. If this is expanded to team level peer reviews, with multiple participants, then the number of errors found (and subsequently fixed) increases.

However a successful design and implementation review needs to start with the correct attitude. Most people (and maybe engineers more than others) become hostile when subjected to reviews. The key to making these reviews effective is for each member of the review to adopt an attitude of “united we stand, divided we fall.” The goal is not to criticise but rather check, validate and verify. The aim is to work as a team for the greater good of the project.

Level of integration

Using a code/design review reduces costs simply because the more integrated any component is, the wider the impact of changes. The wider the impact, the higher the costs. Code which hasn’t yet been committed to the source repository has the lowest level of integration. Fixes at this point are low impact and low cost. Code which is incorporated into a working system, has a high level of integration and a subsequent high level of impact. Changes to that code now (to fix a problem) impact other parts of the system which increases the resulting cost of the fix.

This “level of integration versus cost” rule applies even more to design flaws. A running system containing a flaw in the design of one of its components demonstrates a high level of impact due to its high level of integration. Imagine a database, network protocol or work flow which needs to be changed. The change to this fundamental system component has repercussions across the whole system resulting in high costs to any changes.


Using peer design reviews and peer code reviews reduces the number of bugs and the associated cost in fixing those bugs. Handled correctly they are a valuable tool in making the SDLC and overall project a success.

Latest White Papers

Related Resources

AWS re:Invent 2022: Everything You Need To Know

AWS re:Invent 2022: Everything You Need To Know

Miss out on AWS re:Invent 2022? Or, just looking for a recap on the latest AWS updates and releases from the event? Check out the summary below. What is AWS re:Invent? AWS re:Invent is an annual conference hosted by Amazon Web Services (AWS) for developers, customers,...

Solving for the “Islands of Jenkins”

Solving for the “Islands of Jenkins”

In October 2022, I wrote a blog post entitled “Scaling Jenkins for the Enterprise”.  Within it, I described the “Islands of Jenkins” problem organizations face. Essentially, this problem stems from companies using an open-source Jenkins installation for each team, but...

Infrastructure as Code with Terraform

Infrastructure as Code with Terraform

Before we begin to talk in detail about this topic, we should clarify some definitions first.  The first term comes from the DevOps movement where IT Operations staff use the concept of revision history/version control by using the concept of infrastructure as code. ...