4 Ways to Increase Software Quality with Peer Review
Last week, we discussed steps development teams can take to improve the quality of their software. Among those was peer review, which involves having a developer and one or more of their colleagues sitting down to scan a section of code for bugs. In addition to being one of the easiest, fastest ways to catch defects early, peer review has the benefit of being a social activity, allowing developers to assist each other and spread information.
However, there are many different types of peer review, and not all of them will meet a company’s needs, so how do you know which one is right for you?
Good news, we already did the work for you! This week, we’ve outlined the basic processes behind the four major forms of peer review, as well as the pros and cons, in order to help you pick out the best review process for you.
1. Inspection
Pros: Thorough, structured, spreads out the work
Cons: Lengthy, must be done early in the process, intensive
Perfect for: Large companies that have a structured development hierarchy in place.
Inspections are the most systematic and rigorous type of peer review. They are typically made up of a team of reviewers led by an experienced moderator and they follow a well-defined, multistage process with various roles assigned to participants. Often times, a checklist is used to guide reviewers and ensure that no potential defects or vital pieces of code are skimmed over. According to Seven Truths About Peer Reviews, having regularly scheduled inspections is one of the best business practices, and the ideal time to hold them is when a large product is approximately 10% completed.
The stages of a software inspection. Image courtesy of cs.uic.edu.
The problem with inspections is that they’re incredibly lengthy, and a review team requires at least 3-8 developers (according to Why Code Inspections Fail). In addition to the time it takes to actually review the code, time must be set aside for the moderator to prepare notes for an introductory meeting that involves explaining the purpose of the code and the design idea behind it. Then, the reviewers are given the code to first test for readability without looking for defects, since a misunderstanding of the code can indicate a fault in the material. Once the readers have presented their interpretations of the code and everyone is on the same page, only then can the actual check for defects begin. It takes an estimated 9 hours of review per 200 lines of code to complete an inspection, and many companies don’t have the resources to dedicate to reviewing all their code so intensively.
2. Pair Programming
Pros: Promotes knowledge transfer, code is reviewed as it’s created
Cons: Labor intensive, lacks outside perspective
Perfect for: Companies with large development teams, where developers have similar levels of expertise
In pair programming, two developers work together at the same workstation to produce code. Typically speaking, only one of the developers will be typing at a time while the other observes, allowing for continuous discussion and review. This enables developers to pool their knowledge together and because the reviewer is present during the creation process, it helps catch potential defects as they are formed, if not occasionally preventing them all-together.
A graph displaying the quality and predictability of software based on how frequently pair programming is implemented. Image courtesy of zeroturnaround.com/rebellabs.
However, there are two drawbacks to pair programming; the first is that it lacks the outside perspective of someone who has not worked on the code that most other forms of peer review include. Because the reviewer is so heavily involved in the creation of the code, it can be hard for them to review objectively, much like how a writer will unintentionally overlook their own typos. Supplementing pair programming with another form of peer review can add a fresh pair of eyes. However, this ties to the second issue with pair programming; it is deceptively time consuming. Most other forms of informal review only require 15 to 30 minutes of another developer’s time, but in pair programming, two developers are assigned to a single project full time instead of one, thus tying up double the resources. Two heads are better than one at producing quality code, but it’s up to the company to decide if the quality is worth the cost.
Leave A Comment