This is the latest title from a well-known author in this subject area. Alan Davis has this to say in his brief Foreword:
Bob has had a history of providing us with short treatises on the many software disasters that have occurred over the years. I have been waiting for him to distil the common elements from these disasters so that we can benefit more easily from his many experiences. The 55 facts that Bob Glass discusses in this wonderful book are not just conjectures on his part. They are exactly what I have been waiting for: the wisdom gained by the author by examining in detail the hundreds of cases he has written about in the past.
In the first four chapters (About Management, About the Life Cycle, About Quality and About Research) Robert Glass presents 55 'facts'. Each is presented with a single sentence introduction (e.g. fact 7: Software developers talk a lot about tools, but seldom use them.) Under that heading you will find four sections: Discussion, Controversy, Sources and References.
The final three chapters (About Management, About the Life Cycle, and About Education) present 10 fallacies (for example, fallacy 3: Programming can and should be egoless. and fallacy 10: You teach people how to program by showing them how to write programs.) are presented in a similar format.
The author has a comfortable writing style that makes it easy to read and understand. Of course, the main reason for writing a book such as this one is that much of the content will be considered controversial by many of its potential readers. I never advocate thoughtless reading of technical books, and that includes thoughtless rejection as well as acceptance.
The biggest problem is that different items in this book are addressed to different participants. By that I mean that the people who have the power to respond to them vary from managers, through system architects and programmers to educators. This means that the individual reader is only in a position to respond to parts of the book. I hope that many of you will read the whole of this book but not then proceed on the basis that you are OK and what really needs fixing is the work of other types of participant.
This is a book that deserves to be widely read by participants in software development, and then discussed, understood and acted upon.Non-Programming
