Review By: Kamesh Pemmaraju
07/21/2003The author distills his forty-five years of software engineering experience into fifty-five “facts” and ten “fallacies.” According to the author, these facts and fallacies are the key contributing factors for the success or failure of software projects. Many of these facts (and some fallacies) are dated and mundane. But what makes them worth reemphasizing is that they are often forgotten, misused, or misinterpreted.

Many software professionals will find these facts and fallacies highly controversial, stimulating, and thought-provoking. While reading this book, you may find yourself disagreeing or sometimes just surprised. Other times you may be nodding your head in agreement. Regardless of your reactions, there is plenty of food for thought here and controversies galore. The author acknowledges these debatable issues by explicitly discussing the controversies surrounding them.

The book organizes each fact and fallacy in exactly the same pattern: a headline Summary followed by a detailed Discussion of the topic, and then a synopsis of the Controversy around the topic and finally Sources and References. Facts are categorized into Management, Lifecycle, Quality, and Research while Fallacies are categorized into Management, Lifecycle, and Education. This excellent organizational style makes the book very easy to read and immediately accessible. It allows you to jump to any topic of interest just by glancing at the table of contents. The writing style is simple, straightforward, and sometimes witty.

In discussing many of these facts and fallacies, the author simply describes the problem or issue, but doesn’t propose any solutions. To his credit, the author sets this expectation up-front in the introduction chapter by acknowledging that this is a what-is book and not a how-to book. The author does, however, provide references and sources where potential solutions to these issues have been discussed.

While I agree with many of the facts and fallacies, there are a few I found particularly interesting, a few others I found surprising, and yet a few others I disagreed with.

Consider fact #5: “Most software tool and technique improvements account for about 5 to 35 percent increase in productivity or quality.” People buy into the hype of order of magnitude improvements using such tools and techniques—that is, if the tools and techniques are used at all. The large number of unused shelfware bears testimony to fact #7: “Software developers talk a lot about tools. They evaluate quite a few, buy a fair number, and use practically none.” These facts are particularly important for managers to think about before they consider investing a substantial amount of money into new tools and techniques.

Fact #21: “For every 25 percent increase in problem complexity, there is 100 percent increase in solution complexity.” This is little known and caught me by surprise. What surprised me specifically was the 1:4 factor in solution complexity. It helps explain why many people underestimate software projects.

The most controversial fact in my opinion is Fact #47: “Quality is not user satisfaction, meeting requirements, meeting cost and schedule targets, or reliability.” The author claims that these definitions of quality are all patently wrong. He defines Quality in Fact #46: “Quality is a set of attributes” and then goes on to list and describe those attributes. I don’t think it makes sense to define quality without regard to what is valuable and important to the user. After all, quality is in the eye of the beholder.

The fallacies section is equally controversial and I disagree on a couple of these fallacies. Take for example Fallacy #1: “You can’t manage what you can’t measure.” But we do manage things we can’t measure all the time. But without proper measurements, we will forever be muddling in the dark, not learning from the past, and not knowing whether we are improving at all.