When I was in an organization that had severe code quality problems, the advice in the book seemed really useful for my attempts to teach - more ways to help engineers learn. My current organization requires code reviews, but the culture around them is decidedly informal, but they seem to work well enough that I'm not sure I'm going to try putting this book's more-formal recommendations to use there. ( )

Chapters 1-2 describe the rationale behind conducting software reviews, 3-8 the process of conducting a review (using a few different kinds of processes, although a formal inspection is clearly the author's, and the literature's, favorite), and 9-12 instituting a review process.

Many of the seminal articles on software reviews are specifically geared toward code reviews, but this book takes requirement specs into account. It would be nice if the author also included some details about/examples of reviewing prototypes, sets of use cases, and user documentation.

Most of the book seemed a little "well, duh" to me, but there were a few interesting tidbits here and there about preparing for and moderating a formal inspection. ( )