Facts and Fallacies of Software Engineering

Post date: Oct 08, 2011 4:49:40 PM

Fundamental and Frequently Forgotten

As Robert L. Glass points out in his introduction, and his book title suggests, this book is built around "a laundry list of facts and fallacies about building software". But there is something special in that laundry list: it tries to collect what we ought to know about software development but we frequently forget to remember, as well as some beliefs we give for granted although they are, at least, misleading (just plain wrong for Mr. Glass).

Given its topic, it is not surprising that the book original title was "Fifty-Five Frequently Forgotten Fundamental Facts (and a Few Fallacies) about Software Engineering", alias the F-Book. Somehow, the book title was shortened for marketing reasons and it lost the emphasis it put on the importance of the topics discussed.

The book is clearly written and easy to read, full of wisdom and with some doses of wit, just as the columns "Bob" Glass periodically writes for Communications of the ACM and IEEE Software. Moreover, the facts it examines are essential to software development activities and, although their references might change, their fundamentals will never be outdated. That makes this book a great book in comparison to the myriad of computer books which are written about the hottest topic of the day and whose relevance will not last much longer than trade magazines.

The facts and fallacies in this book cover the whole software life cycle, although several underlying themes recur throughout the book, such as the inherent complexity of software development (remember that software systems are probably the most complex systems ever built by humans) and the irrational hype which plagues our field (as exemplified by one-size-fit-alls advocates).

While you will find some classic facts such as "Adding people to a late project makes it later", as well as discussions of poor estimation and unstable requirements as the most common causes of project failure, you will also find some shocking facts and all of them will give you food for thought. Here is a sample of what I found particularly enlightening:

• • 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 (Fact 12).

  • The answer to a feasibility study is almost always "yes" (Fact 14).

  • Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical (Fact 22).

  • Missing requirements are the hardest requirements errors to correct (Fact 25).

  • One hundred percent [test] coverage is still far from enough (Fact 33).

  • Better methods lead to more maintenance, not less (Fact 45), since "enhancements represent roughly 60 percent of maintenance costs" (Fact 42).

Apart from the 55 facts which are dissected in the first part of the book, the author has chosen ten common misunderstandings in software engineering. These fallacies include pearls such as "given enough eyeballs, all bugs are shallow" (Fallacy 8), "the way to predict future maintenance costs and to make product replacement decisions is to look at past cost data" (Fallacy 9), and "to estimate cost and schedule, first estimate lines of code" (Fallacy 6). You will probably find yourself nodding as you read this part of the book and you will probably get shocked by some of the ideas you will find in this entertaining book, if not merely disturbed or plainly annoyed.

Why don't we learn to read program before we try to learn how to write them? That's the usual way we would learn a new language. Moreover, "60 percent of software's dollar is spent on maintenance, and 60 percent of that maintenance is enhancement" (the 60/60 rule) and "understanding the existing product consumes roughly 30 percent of the total maintenance time."

Some people might the book style somewhat irritating, since its contents are presented as more or less independent sections. Those sections collect Glass' wisdom in snippets which include a discussion of a particular fact, the controversy surrounding the fact, and some pointers to further reading. Although academics might prefer an alphabetical listing of hundreds of references, I have particularly enjoyed the short annotated bibliographic entries which are scattered throughout the book, in spite of the duplications which unavoidably appear when a particular reference is cited in several places. Somehow, almost every classic reference has its place in the F-Book.

This book is an invaluable resource for those people preparing to be software engineers in the future and also for those practitioners which want to refresh what they ought to know or just to reinforce what they believe in spite of existing controversies (mostly from "hypesters"). Since the book covers topics which are usually controversial, this book will also give you arguments for the next time you will find yourself trying to refrain your team of doing things the wrong way. If you love software development, you'll love this book. Enjoy it!

-- Fernando Berzal, Dr. Dobb's Journal ERCB, 2003