Seven Deadly Sins of Software Reviews

Member Submitted

brain damage on the part of the reviewer. Then, when the reviewers realize the meeting time is almost up, they hastily regroup, flip through the remaining pages quickly, and declare the review a success. In reality, the material that is glossed over likely contains some major problems that will come back to haunt the development team in the future.

Solutions: The kind of reviews I'm discussing in this article have one primary purpose: to find defects in a software work product. Solving problems is usually a distraction that siphons valuable time away from the focus on error detection. One reason inspections are more effective than less formal reviews is that they have a moderator who controls the meeting, including detecting when problem-solving is taking place and bringing the discussion back on track. Certain types of reviews, such as walkthroughs, may be intended for brainstorming, exploring design alternatives, and solving problems. This is fine, but don't confuse a walkthrough with a defect-focused review such as an inspection.

My rule of thumb is that if a problem can be solved with no more than 1 minute of discussion, go for it. You have the right people in the room and they're focused on the issue. But if it looks like the discussion will take longer, remind the recorder to note the item and ask the author to pursue solutions off-line, after the meeting.

Rarely, you may encounter a show-stopper defect, one that puts the whole premise of the product being reviewed into question. Until that issue is resolved, there may be no point in completing the review. In such a case, you may choose to switch the meeting into a problem-solving mode, but then don't pretend that you completed the review as intended.

Reviewers Are Not Prepared
Symptoms: You come into work at 7:45AM and find a stack of paper on your chair with a note attached: "We're reviewing this code at 8:00AM in conference room B." There's no way you can properly examine the work product and associated materials in 15 minutes. If attendees at a review meeting are seeing the product for the first time, they may not understand the intent of the product or its assumptions, background, and context, let alone be able to spot subtle errors. Other symptoms of inadequate preparation are that the work product copies brought to the meeting aren't marked up with questions and comments, and some reviewers don't actively contribute to the discussion.

Solutions: Since about 75% of the defects found during inspections are located during individual preparation, the review's effectiveness is badly hampered by inadequate preparation prior to the meeting. This is why the moderator in an inspection begins the meeting by collecting the preparation times from all participants. If the moderator judges the preparation time to be inadequate (say, less than half the planned meeting time), she should reschedule the meeting. Make sure the reviewers receive the materials to be reviewed at least two or three days prior to the scheduled review meeting.

When reviews come along, most people don't want to interrupt their own pressing work to carefully study someone else's product. Try to internalize the fact that the time you spend reviewing a co-worker's product will be repaid by the help you'll get from your friends when your own work comes up for review. Use the average collected preparation times to help reviewers plan how much time to allocate to this important stage of the review process.

The Wrong People Participate
Symptoms: If the participants in a review do not have appropriate skills and knowledge to

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.