(This was originally written as a review for DDJ but I keep getting caught in a spam filter there so reviews will now show up here)

Since I started reviewing books, I’ve been sent at least one or two a month to read. I have various strategies for managing the queue, but once in awhile a book arrives whose title and concept makes me push it to the top of the pile immediately. Dorota Huizinga and Adam Kolawa’s new book, Automated Defect Prevention, is once such book. It is unfortunate then that I cannot write a glowing review of it.

Rarely is anything as positive or negative as it seems, and this holds true for this book. I thought the size of it was appropriate, as was the choice to publish it as a hardcover. I also liked the layout with each chapter following a similar structure which would make looking up information easier if being used as a reference. I also was impressed by the design section where they laid out their Critical Aspects of Architectural Design. This could easily be turned into a checklist to drive the product’s testing efforts. It should also be noted that Dr. Kolawa is the CEO of Parasoft, a large vendor of testing tools. I am always skeptical when someone in that sort of position writes a book relating to their market for fear of book scale advertising. Automated Defect Prevention does a remarkable job of being vendor and technology neutral throughout and I think Parasoft is only mentioned one or two places, and they were relevant to the topic being discussed.

Those positives aside, there are three things that prevent me from recommending Automated Defect Prevention.

Automated Defect Prevention is a complete software development methodology that leverages automation for, amongst other things, repetitive tasks, organize project activities and tracking project status. The problem with their methodology is that it feels like a philosophical mash-up of Deming, CMMi and Six Sigma. The Six Sigma heritage shows through with every practice having a measurement section even if it sometimes feels unnatural; when discussing requirements and design for instance. CMMi is brought into the mix through the customization of the best practices. This is the equivalent of tailoring a CMMi practice area.

While Automated Defect Prevention does have moments of agility the methodology appears to be advocating the classic waterfall style of project management with its inherit problems. Iterative design is mentioned, as is unit testing, but those are undone by the large upfront test design that occurs both for the unit and functional tests. Unit tests tend to work best when they are evolutionary which is one of the primary benefits the Agile community has given to development world. They also recommend that modules be owned by specific developers which removes the notion of shared code ownership / responsibility and creates knowledge silos and clusters within the organization which can be problematic in my experience.

The main problem I had with this book however is its use of the term Best Practices and its implication that one particular methodology is appropriate for any organization. In software development the existence of Best Practices is a myth. There are certainly plenty practices that ‘Have Worked Well For Others And May Or May Not Work Well For You’ and Automated Defect Prevention even presents a number that I often recommend to people. The problem is that the target audience, principally project managers, graduate and post-graduate students are not likely to have the experience to recognize this and attempt to implement the presented ideas based solely on its inclusion in the book without questioning why they are doing it or whether it is appropriate in their context. The number of companies that adopted Six Sigma (it too was a Best Practice) in the late 90s only to very publicly reject it as a mistake (3M most recently) shows the danger in this.

An excellent title is certainly part of the process in making a book a success. It needs to be backed up by equally excellent content. If you are looking to improve your deliverables in either quality or delivery date through a formal methodology, you would be better served getting a well reviewed book on each CMMi, Six Sigma and Agile and creating a custom one that was designed to work for you than try to implement someone else’s and end up customizing all their Best Practices to fit your context. And that is a shame; nothing appeals to the tester portion of me than the utopian ideal of Automated Defect Prevention.