ACCU Home page ACCU Conference Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Google+ ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

Search in Book Reviews

The ACCU passes on review copies of computer books to its members for them to review. The result is a large, high quality collection of book reviews by programmers, for programmers. Currently there are 1918 reviews in the database and more every month.
Search is a simple string search in either book title or book author. The full text search is a search of the text of the review.
    View all alphabetically
Title:
Peer Reviews in Software: A Practical Guide
Author:
Karl Wiegers
ISBN:
0 201 73485 0
Publisher:
Addison-Wesley
Pages:
232pp
Price:
£30-99
Reviewer:
Silvia de Beer
Subject:
management
Appeared in:
14-3
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.