Book Review - "Glitch - The Hidden Impact of Faulty Software"

I have a great interest in the topic of software defects, their impact and how software failures happen. Books in the past such as "The Day the Phones Stopped", "Bad Software" and "Fatal Defect" have been great sources of documenting what has gone wrong due to software defects. These books serve as case studies for anyone who is involved in creating, testing or buying software products.

So, I was excited to see that a new book has been written on the topic. I'm not crazy about the title of "Glitch" because it tends to convey that a problem is minor. We see this a lot in the popular media as major system failures are described as glitches. I think the problems that Papows describe in this book are more than minor ones. Setting the title aside, I was happy to see a very recent accounting of computer failures in many domains - financial, government, medical, etc. Of course, I'm not happy for the problems, but it's good to see recent information.

This book is written at a level that non-technical people can understand and technical people can read without feeling insulted. That's a nice balance. The information is also sourced well. When it comes to reporting about failures, there are ten sides to every story. But having some objective sources is helpful.

To me, the strongest chapter was Chapter 8, "The Way Forward." In this chapter, Papows (who was the former President and CEO of Lotus Development) describes what organizations and individuals can do to help reduce the risk of computing failures. This is the only place QA and testing are mentioned in the book, which was a little disappointing to me, but I come from a biased perspective. I think people need to understand the project management reality of rushed deadlines, skimpy testing and lax attitudes toward quality to truly understand why software fails. This book gets into that to some degree, but not very deeply.

In fact, much of the book is written from a top-down perspective as opposed to an "in the trenches" perspective. I was hoping for a more detailed analysis of why some of the problems happened.

I can recommend this book to business managers to raise awareness of software risks and to software quality professionals who need good examples of past failures to make the case for better software development and testing processes. However, it may disappoint those looking for root cause analysis of software defects.