Review By: Harry Acosta
07/09/2010

This book should have been called Disasters in Software Quality Engineering. It is an excellent compilation of good things gone wrong because one or more software application practices—designing, project management, marketing—have not been followed. It is also a testament to the consequences of not following through on a vision or just picking the wrong strategy. Of course, this topic is not limited to software but can also be applied to many other technology projects that suffered the same fate.

The organization of the book is very straightforward and easy to follow. Chapter one is a nice introduction to stupidity in product design and marketing. It is also where the author presents his case that stupidity is both quantifiable and identifiable. Chapters two through eleven give a detailed review of twenty years of technology and technology companies. Sometimes the author has been very close to the actual situation, and this provides a refreshing first-hand perspective. Especially interesting is Chapter 11, where a detailed history of the Internet and the technology advances around it are explained. Chapter 12 talks about the continuing battle between proprietary and open source software (including the recent Sony rootkit fiasco) while Chapter 13 deals with some anti-stupdity counseling and prevention. If the reader does not have the time to read through the whole book, Chapter 14 is a timesaver that summarizes and analyzes each case.

While this book is a great read for the technology history buff, it becomes really valuable when all its advice is actually followed and implemented. It provides the insight of an advanced marketing and corporate strategy course for those who don't have the time to get an MBA degree. It also provides very good advice to software quality engineers and gives a lot of examples of what might happen if its practices are not properly followed.

However, in almost all cases the situations presented could be prevented provided that sound software quality practices are followed. For example, understanding and delivering what the end-user wants when the user wants it (key concepts in software quality engineering) are always most important to user acceptance.

As another example, the author is very clear on the uselessness of recoding perfectly good code or even writing code with a level of quality that does not add value to the end-user (or that he is not willing to pay for). This is another key aspect of good software quality engineering.

I would recommend this book to the decision makers, strategists, and marketing people who are willing to learn from the failures of other companies and to look for new ways to do things.