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. A major contributor to schedule overruns is inadequate planning of the tasks that must be performed. 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. The only way to create realistic estimates of the time needed is to keep records from your reviews of different work products. 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.
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.