Facts and Fallacies of Software Engineering

Robert L. Glass (2002)
Review date: December, 2008

This book's title says it all. The book is really a collection of 55+10 statements that the author packages as software engineering facts and fallacies, organized in such order. These, in turn, are further divided into sections about management, the software life-cycle, quality, and research.

Each statement is broken down into a discussion, a section where potential controversies are discussed, and finally sources and references.


This is a good book, written by a true industry veteran, and is therefore very valuable because of its insights and conclusions. However, this is not the first and only book you need to read on software engineering. The researched facts do make you think, and there are really some gems in there, but again, this is a book you should read more for fun than for obtaining hard core knowledge.

It's difficult to say more about this book without mentioning some of the facts. Try this:

  1. The best programmers are up to 28 times better than the worst programmers [...]
  2. Software developers talk a lot about tools. They evaluate quite a few, buy a fair number, and use practically none.
  3. Reuse-in-the-small (libraries of subroutines) began nearly 50 years ago and is a well-solved problem.
  4. Design pattern reuse is one solution to the problems inherent in code reuse.
  5. Missing requirements are the hardest requirements to correct.
  6. Postdeliver reviews (some call the "retrospectives") are generally acknowledged to be important, both from the point of view of determining customer satisfaction and from the point of view of process improvement. But most organizations do not do postdelivery reviews.
  7. Maintenence typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important cycle phase of software.

This are but samples, and if you like this style, the book will not make you disappointed. At the lowest level it provides you with arguments for introducing some practice of doing things differently and selling this to your boss. The scientific approach and the numerous sources make many of the assertions credible. However, this book suffers from the problem of circular references; the author quotes his own work quite often. While there's nothing strange about a researcher doing this, I would say, in my humble opinion, that it happens too frequently and introduces a certain bias. Beware.

Another problem that this book suffers from, is the fact that it's sort of outdated. Some of the references stretch as far back as the seventies. One could, of course, turn this into a strength rather than a weakness, since these "old" references seem to shed light on problems that the industry still suffers from today, and this makes the reading quite enjoyable too.

Lastly, it's quite obvious that the author is not a fan of agile methods and open source. The reason for this is, I guess, his extensive experience of heavy-tech large-scale projects, that could probably not be very well managed using agile methodologies. Personally, I sort of believe in agile methods, but this book has opened my eyes to some problems inherent to them. Then again, this book was published in 2002, when XP, Scrum, and TDD were new and rather untested. Anyway, the maturity of some agile methodologies may make some parts of this book obsolete.

So, is this the book you want to take with you to a deserted island? No. Is this a book loaded with interesting facts for those that have been working in the field for quite some time? Yes. Regardless of the tone of in this review, this is a very good book, but should be read "on the margin".

Who should read this book

Experienced professionals who want to compare today with yesterday and who want arguments for proper time estimation and requirement gathering will find this book valuable. Project managers and CEOs that want some numbers put on things may like this book too.


  • 2015-09-29

    It's been almost one and a half year since I reviwed a book! I've been too absorbed by Writing my own. Anyway, I'm back with Jeff Patton's relatively...
  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.