How peer review leads to quality code

If you could deploy existing resources to improve the quality and timeliness of your software development projects, you'd probably jump at the chance.

So what is this magic elixir?

The peer review.

Peer reviews, or, as they're sometimes called, peer code reviews, or just code reviews, are an excellent way of making the most use of your development talent while minimizing the time spent on finding and fixing bugs.

What do they involve? Essentially, a developer teams up with a peer, and each developer reviews the other's code to look out for quality, better ways to do things, and to eliminate duplication and redundant coding efforts. The developer walks through his code, explains his logic, shows how he has developed the concept or the story that he has been working on. The peer developer suggests where errors might lie, helps to solve thorny issues and in general works to improve the quality of the code.

Make peer review the new normal

While peer review is an essential part of both the scientific and academic publishing world, it seems to have only recently gained some momentum in software development, where even modest applications can have thousands of lines of code -- and thus tens of thousands of opportunities for error.

Successful peer reviews are a significant indicator of quality and, if implemented regularly, peer reviews can save a lot of time and money. If errors are identified and corrected before they're integrated into further builds, there will be fewer defects and projects will get delivered more quickly. Indeed, the book "Code Complete" indicates that after instituting peer review, "[t]he Aetna Insurance Company found 82 percent of the errors in a program by using inspections and was able to decrease its development resources by 20 percent." Reducing your coding expenses by a fifth is a real savings, and it's done entirely by utilizing the human resources you already have.

If you're game, you could quietly implement a peer review program by tapping a couple of programmers who respect each other and the process, and watch how other developers or teams react when they see the quality of the code improving. (Of course, this could already be happening in your organization on an informal basis.) Or you could take a top-down approach and simply implement a culture and process of peer review as part of the new normal.

5 common objections to peer review and how to overcome them

However you get there, you're bound to hear some grumblings as you begin a peer review program. Here are some common complaints:

• Peer review is a waste of time and just gets in the way. Unfortunately, some of your team members are tired of bureaucracy and will initially react to a peer review implementation with dread and pushback. There's a good possibility that these folks will be your weakest developers as well, the ones who could most benefit from and improve through regular peer reviews. To combat this, explain that many eyes are better than one, that code quality will improve as a result, and that quality measures are important to everyone in the company.
• I don't handle criticism well. Inherently, peer review means a critique of code and some developers certainly will have a hard time critiquing the code without it getting personal. This is a skill to be honed and matured over time. To make these sessions more productive, consider starting peer review earlier in the process -- using test cases, test plans, requirements and user stories, even architecture discussions -- so that actual code is not the only element being reviewed. This allows your teams to develop a comfort level with having their thought processes shared and improved at all times.
• I'm not good enough to do a peer review with another person on my team. It's true that as peer review starts, some folks will not quite pull their weight while others will over-deliver. This imbalance even out over the first year, and as an added bonus, this type of regular review makes annual performance reviews easier. Management's job of identifying the best and the brightest will be easier, too, as it will become abundantly clear who's capable of delivering for your team and who might need to be re-assigned or shown the door.
• I don't have time to peer review -- we have a tight schedule to keep and our deadlines don't allow for the time to do this sort of systematic review. Part of your culture should say that tight deadlines are no reason not to perform reviews. In essence, there will always be a review -- it just might be at the wrong time (after a build is destroyed that requires an all-nighter to fix, for instance). The right times are early and often, and in general, if peer code reviews are performed this way, projects often are delivered early. Go figure.
• I don't know who to pair with. This is the sort of problem that your direct reports probably ought to hash out, but leave the door open for the developers to sort this out directly among themselves. When in doubt, pair seasoned professionals with newbies...for obvious reasons.

Like any cultural change, it takes time. But with your executive sponsorship and buy-in, it can succeed. Your best developers will appreciate the fact that good quality code is the point of the exercise. Your junior coders may hone and improve their skills by virtue of seeing first-hand how more experienced programmers write. And you may save time and money by wasting fewer resources debugging errors, and getting more done in the process with the same headcount.

What's not to like?