Facts and Fallacies of Software Engineering [Kindle Edition]

Facts and Fallacies of Software Engineering is divided into 55 facts and 10 fallacies. Each fact and fallacy is presented in the same way. There is a headline/slogan that summarizes it, usually one or two pages of Discussion giving more details, then a Controversy section describing what (if anything) people disagree about and finally Sources and References.

The 55 Facts are divided into the following sections and sub-sections: Management (People, Tools and Techniques, Estimation, Reuse, Complexity), Life Cycle (Requirements, Design, Coding, Error Removal, Testing, Reviews and Inspections, Maintenance), Quality (Quality, Reliability, Efficiency) and Research.

The 10 Fallacies are divided into Management, Life Cycle and Education.

This way of organizing the material works really well, and makes the book very accessible and easy to read. It also allows you to jump around and read what interests you the most first (which is what I did, although I eventually read all of it).

Many of the facts are well known (for example Fact 3 "Adding people to a late project makes it later", Fact 16 "Reuse-in-the-large remains a mostly unsolved problem" and Fact 24 "Requirement errors are the most expensive to fix during production"), but that doesn't matter. It is actually good to be reminded of these facts even if you already know them, and the author does a very good job of summarizing them.

Another thing I like about the book is the Sources and Reference parts (although I think they might as well have been combined into just one Reference section). Often there are references to research papers where the original fact was presented. It is nice to know that what is presented as a fact is indeed a fact that has been validated by research, and not just the opinion of the author (although there is certainly room for opinions in a lot of places as well).

There are also lots of references to other books on software engineering, and a lot of the classic books (like The Mythical Man-Month, Peopleware and Design Patterns) are referenced. So there is plenty of leads in case you want to find out more about a certain fact.

Among the facts I liked the most were Fact 12, Fact 21 and Fact 26.

Fact 12: "Since estimates are so faulty, there is little reason to be concerned when software projects do not meet estimated targets. But everyone is concerned anyway". This fact and the related ones simply state that when a project is late, it is very likely because the estimated time to complete it was unrealistic. Very true.

Fact 21: "For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution." I had never seen this fact before, but it does ring true to me. And as the author writes, it explains a lot of the other facts in the book as well.

Fact 26: "Explicit requirements 'explode' as implicit (design) requirements for a solution evolve". In other words, each explicit requirement leads to many more implicit requirements (by a factor of up to 50). This too I had never seen stated, but I definitely recognize this from my own experience.

The Fallacies section list ten common misunderstandings in software engineering, and this is where I disagree on a couple of points. Fallacy 7 states "Random test input is a good way to optimize testing". I agree that it can not be the only test approach, but since he also writes "It may or may not survive as a test approach", he is skeptical to it in general. My own experience is that it is an invaluable complement that helps flush out numerous what I call "timing dependent" bugs caused by the nature of asynchronous events.

I also don't think all his arguments in Fallacy 8 are valid. I agree that since there is no data demonstrating the truth of "Given enough eyeballs, all bugs are shallow", we should not just accept it as truth. But I think he misses the point when he refers to research showing that inspections don't get much extra benefit beyond 2 to 4 participants. My interpretation is that the "enough eyeballs" are not so much inspecting the software in question as running it and debugging it when there is a problem. And the "all bugs are shallow" should not be interpreted too literally. Of course the bugs may still be difficult, but if many people look at it, the chances of someone solving it fairly quickly increases.

Those two examples notwithstanding, I did find myself nodding my head and saying "yes, I agree with that" almost all of the time reading this book.

There are many more interesting facts that I have not commented on, and if you are interested in software engineering I highly recommend this book.

Take the following two items as examples:

"The 60/60 rule: 60 percent of software's dollar is spent on maintenance, and 60 percent of that maintenance is enhancement."

"Understanding the existing product consumes roughly 30 percent of the total maintenance time."

That implies that one of the most valuable skills you can teach a Computer Science student is how to *read* code. But as Glass points out (and he taught graduate students for a while) CS courses only teach students to *write* programs, and then they don't often grade the code on readability.

The section on design, which Glass describes as the most intellectual phase of a software project, is the best description of how software designers actually work that I've ever read. He claims that top-ranked designers routinely ignore or subvert the methodologies used by their shops in order to do the job the right way. He has an especial warning for anyone trying to develop anything other than the most trivial program using XP.

The ten fallacies may have taken some well-known quotes out of context. Surely Eric Raymond of the open source movement didn't really mean, "Given enough eyes all bugs are shallow", to be taken literally. Either way, the point Glass is trying to make is that, without proof, we shouldn't *assume* that open source code is less buggy than proprietary code.

Facts and Fallacies of Software Engineering is aimed at two audiences: those without Glass' 45 years of programming experience, and those who have it but, like all good professionals, want to refresh the basics. Since some of the wisdom came with useful statistics that I've never seen published before, I'd recommend the book to anyone involved in developing or maintaining software.