I was very interested in this book before I started reading it. I was expecting that after reading this book, I would be capable of easily introducing peer reviews in our team. However, that will not be so easy. To do proper inspections, it is required to have checklists to help the reviewers in their inspection process. Alas, the book provides no help on how to set up such checklists. I think this is the essential missing part of the book, which makes it less practical. One would have to do additional work and probably some trial and error to set up check lists for different parts of the software development process. I think this is essential because reviewing products without having some guidelines and set standards is less effective.

Apart from this lack in guidance to set up checklists, the book is thoughtfully written, although I found it a bit too repetitive in cases. The book starts with explaining the formal spectrum of peer reviews: inspection, team review, walkthrough, pair programming and peer desk check. Then it continues to describe the inspector roles: the author, the moderator the reader and the reviewers. The various stages in an inspection process are described; planning, preparation, meeting and possible rework and follow-up. Afterdescribing in more detail the inspection process, the author explains how one could analyse the inspection data. One must keep track of the effort spent on the inspection process, the number and type of defects found and the size of the product reviewed. The importance is stressed that defects found should not be used for personal performance appraisals and inspection data should stay confidential. Review teams should be small and have a good understanding of what the review process wants to achieve. I found this book an interesting read, but a bit superficial.