How can you not like a book whose first section is called “The most important factor in software work is the quality of the programmers”?
Facts and Fallacies of Software Engineering, the latest book from prolific author and software practitioner Robert Glass, is divided into two sections: the first section presents 55 facts culled from Glass's 45 years in the software field; the second section contains 10 fallacies that Glass says he couldn't resist skewering.
One of the wonderful things about this book is that Glass doesn’t expect us to mindlessly agree with each of his points. The facts he selected are subject to debate and every reader will almost certainly disagree with the author on some. Glass says he selected the facts because they are fundamental but many are too frequently forgotten. Reading the book will provide you with what Glass calls a “rich remembering experience.”
I doubt that Glass considers himself a member of the agile community but his past writings include at least two articles (both available on the Agile Alliance website) where he draws favorable conclusions about agile development. Considering this, it is no surprise that a fair number of the facts in his book can be considered aligned with agile principles. For example, “Design is a complex, iterative process. The initial design solution will likely be wrong and certainly not be optimal.” (Fact 28) Glass doesn’t go so far as to say design should be emergent as it is with test–driven development but this fact is a condemnation of Big Design Upfront.
Similarly, “Software estimation usually occurs at the wrong time” (Fact 9) points out the fallacy of believing we can estimate a project at its outset. Other favorites of mine which are aligned with agile beliefs are: “Software developers talk a lot about tools, but seldom use them” (Fact 7); and, “Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical” (Fact 22).
Glass does a great job of skewering fallacies. For example, he argues that “You can't manage what you can't measure” is a fallacy because “we manage things we can't measure all the time. We manage cancer research. We manage software design. We manage all manner of things that are deeply intellectual, even creative, without any idea of what numbers we ought to have to guide us.”
This book taught me a few new things and, as the author predicted, helped me remember quite a few more. I suspect you'll have a similar experience. Recommended.
