This article is going to be the first in a three-part software engineering best practices series on code reviews. Here, we will focus on what a code review is and why it’s an integral part of a mature software development lifecycle (SDLC) process. In the following installments, we’ll talk about best practices for conducting code reviews and then tools available to facilitate them.
So… What is a code review? Really, it’s nothing fancy or mystical; it’s simply having others look at your code with the option to provide feedback. Actually, doing a code review can be accomplished in a variety of ways and with any number of requirements, but stripped down to its bare essence, it’s a ridiculously simple concept and is a necessity for anyone interested in following software engineering best practices.
If you currently are not doing code reviews — regardless of the size of your organization — you need to change this right now. Maybe you think it adds an unnecessary level of bureaucracy to your development cycle, or you think you’re too small to warrant the effort. In both instances, you’re wrong.
Let’s talk about why code reviews should be mandatory for any serious development effort.
The first benefit of code reviews is catching errors before they’re introduced into production. We all [should] know that it is much cheaper to fix errors as soon as possible and that bugs discovered after release are much harder to resolve. In his book Code Complete, Steve McConnell provides several examples of organizations that succeeded in slashing the number of errors released into production by 80 and sometimes 90 percent. In one specific instance, Jet Propulsion Laboratories estimated it saved $25,000 per inspection as a result of catching errors early!
Persuasive as this all may be, the really interesting part is that catching errors is NOT the main benefit of doing code reviews. There are three other benefits that are easy to miss if you forget the fact that people write code and which outweigh the straight-forward goal of simply catching bugs.
1. Disaster Recovery
Even more important than catching bugs is, what I shall call, the “disaster recovery” facet afforded by doing code reviews. By having developers look over each others’ code (even briefly) you are helping to familiarize them with parts of the program they might not otherwise see. In the event of an emergency, or if the original author leaves or is otherwise not maintaining the code they wrote, seeing the code ahead of any transitional events provides a good leg up toward re-balancing work loads and getting development back up to speed.
This is especially import for small organizations in which one or two programmers can constitute a large chunk of your development force. We build redundancy and fail-safes into our code and the infrastructure it runs on in order to keep operations moving when things go wrong. Your developers — your people — are immeasurably more valuable than your stuff. They are your creative force and are not quickly or easily replaced. That said, people do come and go. Performing code reviews makes your team more versatile, better able to spread out development tasks, quicker to recover from unforeseen disruptive events, and quicker at performing maintenance tasks because they’ve seen the code before.
2. Cultivate Better Programmers
Aside from providing a better understanding of how your project is implemented, code reviews cultivate better programmers. Younger developers are able to both receive guidance from veterans as well as learn new things by reviewing their code. Furthermore, code reviews provide an opportunity to enforce standards and styles that may be difficult to do using automated tools, such as documentation practices or the structure of a class or project. As a result, better code with better documentation is checked in. This directly impacts the amount of maintenance required later and the ease with which any maintenance is performed. It’s nice to hire rock star programmers, but most of the time we need to grow them and code reviews are one means of encouraging a developer’s… development.
3. Better Code from the Start
The final benefit of code reviews I’ll discuss (I’m sure there are more) has to do with peer pressure. I know from experience that the code I write for myself or when I think no one else will ever scrutinize it is [worse] different than code I write when I know I have to present it to someone else. Knowing that other people, who’s opinions I care about, are going to look at my work encourages me to do a better job than I might otherwise.
In a perfect world, we’d do our best 100% of the time, but the reality of human behavior is that we do things differently when people are watching. The social experience of code reviews (done constructively) inspires better code and better adherence to standards of documentation and style. This decreases the burden of performing maintenance operations, driving down the long-term cost of development.
Simply put, code reviews serve to make your organization more robust and efficient. They can catch errors when they’re cheap to fix, strengthen your team’s abilities, add a certain amount of fault tolerance to your organization so that you are better able to recover from disruptive changes, and they result in better code which is more easily maintained. All of these things contribute to lower costs and capable employees, which impacts your ability to hire, retain, and cultivate talented people.
Stay tuned for the next installment in which we look at different ways to do and not do code reviews!
Next Steps:
- Read Software Engineering Best Practices: Code Reviews – Part 2
- Read Software Engineering Best Practices: Code Reviews – Part 3
- Contact SPK and Associates to see how we can help your organization with our ALM, PLM, and Engineering Tools Support services.
- Read our White Papers & Case Studies for examples of how SPK leverages technology to advance engineering and business for our clients.
David Hubbell
Software Engineer
SPK and Associates
