the author. A confrontational style of raising issues exacerbates the problem. Not surprisingly, this makes the author feel beaten down, defensive, and resistant to legitimate suggestions that are raised or defects that are found. When authors feel personally attacked by other review participants, they will be reluctant to submit their future products for review. They may also look forward to reviewing the work of their antagonists as an opportunity for revenge.
Solutions: When helping your team begin reviews, emphasize that the correct battle lines pit the author and his peers against the defects in the work product. A review is not an opportunity for a reviewer to show how much smarter he is than the author, but rather a way to use the collective wisdom, insights, and experience of a group of peers to improve the quality of the group's products. Try directing your comments and criticisms to the product itself, rather than pointing out places the author made an error. Practice using the passive voice: "I don't see where these variables were initialized, "not "You forgot to initialize these variables."
Reviews Are Not Planned
Symptoms: On many projects, reviews do not appear in the project's work breakdown structure or schedule. If they do appear in the project plan, they may be shown as milestones, rather than as tasks. Because milestones take zero time by definition, the non-zero time that reviews actually consume may make the project appear to slip its schedule because of reviews. Another consequence of failing to plan the reviews is that potential review participants do not have time to take part when one of their peers asks them to join in.
Solutions: A major contributor to schedule overruns is inadequate planning of the tasks that must be performed. Not thinking of these tasks doesn't mean that you won't perform them; it simply means that when you do perform them, the project will wind up taking longer than you expected. The benefits of well-executed software technical reviews are so great that project plans should explicitly show that key work products will be reviewed at planned checkpoints.
When planning a review, estimate the time required for individual preparation, the review meeting (if one is held), and likely rework. (The unceasing optimism of software developers often leads us to forget about the rework that follows most quality activities.) The only way to create realistic estimates of the time needed is to keep records from your reviews of different work products. For example, you may find that your last 20 code reviews required an average of 6 labor-hours of individual preparation time, 8 labor-hours of meeting time, and 3 labor-hours of rework. Without collecting such data, your estimates will forever remain guesses, and you will have no reason to believe that you can realistically estimate the review effort on your future projects.
Review Meetings Drift Into Problem-Solving
Symptoms: Software developers are creative problem solvers by nature. We enjoy nothing more than sinking our cerebrums into sticky technical challenges, exploring elegant solutions to thorny problems. Unfortunately, this is not the behavior we want during a technical review. Reviews should focus on finding defects, but too often an interesting defect triggers a spirited discussion about how it ought to be fixed.
When a review meeting segues into a problem-solving session, the progress of examining the product slows to a halt. Participants who aren't equally fascinated by the problem at hand may become bored and tune out. Debates ensue as to whether a proposed bug really is a problem, or whether an objection to the author's coding style indicates