The Seven Deadly Sins of Software Reviews

Software peer reviews are a powerful quality practice, but many teams struggle with them. Here are seven common problems and some solutions.

Karl Wiegers
The Startup
Published in
7 min readMay 13, 2020

--

A group of people sit around a table and look at a wall covered with sticky notes.
Photo by You X Ventures on Unsplash

Technical peer reviews are a powerful software quality practice. In a review, a group of people examine a work product for defects and improvement opportunities. I’ve been a big fan of peer reviews since about 1988 and would never work in an organization that didn’t practice them routinely.

Any type of software work product can benefit from review: requirements, designs, code, tests, plans, documentation, process descriptions. Yet teams often have difficulty getting a review process going. In this article I describe the symptoms of seven common review problems and some solutions.

Sin #1: Participants Don’t Understand the Review Process

Symptoms: Software developers don’t instinctively know how to conduct and contribute to software reviews. Review participants may have different understandings of their roles and responsibilities, and of the review steps. Team members may not know which items should be reviewed, when to review them, or what review approach to use

Team members may not understand the various types of reviews. They may use the terms review, inspection, and walkthrough interchangeably, although they are different methods. This lack of common understanding can lead to inconsistent review practices. Too much material may be scheduled for a single review, because participants aren’t aware of realistic review rates.

People might not be able to judge when a review meeting is warranted and when it’s unnecessary. Discussions can lose focus, drifting from finding defects to solving problems or debating coding style. The results are overlooked defects, frustration, and an unwillingness to participate in future reviews.

Solutions: Team members should be trained to gain a common understanding of effective review methods. Written procedures can help review participants understand their roles and activities, so they can consistently practice effective and efficient reviews.

--

--

Karl Wiegers
The Startup

Author of 14 books, mostly on software. PhD in organic chemistry. Guitars, wine, and military history fill the voids. karlwiegers.com and processimpact.com