Peer code review is an excellent tool for making sure software meets requirements and for identifying and correcting possible bugs that can save reworking time and cost later. Research for the State of Software Development in 2018 report from Coding Sans found 67.66% of software developers use peer review to ensure code quality. Moreover, that number is even higher among top performing software developers; 73.53% of the most successful developers use this method. Peer code review, however, has to be conducted systematically to result in better code—and a better team, if you do it right. Here is some expert advice to keep in mind.
Who Should Review Code?
Karl Wiegers, author of “Peer Reviews in Software: A Practical Guide,” offers guidance on who should be involved in a peer code review and what their roles should be. The code’s author should participate, as well as at least three more, including the author’s peers, team members who will be responsible for components the product will interface with and team members who will base future work on the product. Wiegers points out supervisors should only be included at the author’s request.
Once the team is assembled, a moderator needs to assign roles. The review needs a “reader” who presents parts of the code for inspection and comment, a “recorder” who documents and classifies issues, and a “verifier” who will confirm whether changes were made correctly. Everyone involved in the peer code review act as “inspectors” as the review team goes through code line by line.
Effective Peer Code Reviews Aren’t Marathons, They’re Sprints
The SmartBear book “Best Kept Secrets of Peer Code Review” includes the results of research based on the Cisco Systems programming team to quantify how to conduct an effective peer code review. The findings of that study include:
- Limit reviews to 60 minutes: As with any work that requires concentration and extreme attention to detail, after time, your ability to spot an error decreases. Limiting reviews to 60 minutes, reviewers found between 70 percent and 90 percent of errors. Their effectiveness decreased sharply after an hour.
- Keep the rate at less than 500 LOC per hour: Within that hour, if you are trying to get through too many lines of code, you will miss something. The research showed less efficient reviews at faster rates.
Goals: Better Code and Better Teams
Realize when you are investing time into peer code reviews to ensure code quality that you are also investing in nurturing better developers. Reviews will be educational and especially valuable when mentoring. More seasoned developers will learn what their coworkers are doing and work together to develop new ideas. Everyone learns and grows professionally, and teams can become more cohesive.
In an Atlassian Agile Coach article, Dan Radigan also points out that peer code reviews help Agile teams work together by sharing knowledge—completing the work isn’t dependent on one person’s knowledge. Anyone on the team can step in and work on the code, which gives team members the flexibility to work in a different area or even take a day off.
What’s Your Method?
Evaluate the processes your ISV currently has in place to ensure code quality: Do you need to make changes? The flipside of the Coding Sans finding that the majority of software developers use peer code review, is the statistic that 12.54% of software developers are using “no specific way.” Consider implementing peer code review to elevate your products’ quality as well as your team’s skills. 
