The curmudgeon’s take on the malpractices of software engineering

Software changes at an accelerating pace. People, on the other hand, stay the same. That’s why some software engineering books are timeless classics: They speak to the human rather than the technical side of development. Robert Glass’s Facts and Fallacies of Software Engineering seems to be hailed as one such classic, and I too found this a highly rewarding read.

Sage advice from an experienced curmudgeon

Robert L. Glass is a very experienced software practitioner and researcher, and, if the back cover is to be believed, “the premier curmudgeon of software practice”. However, his willingness to speak his mind in a frank manner does not mean his advice is unfounded. In Facts and Fallacies of Software Engineering, Glass presents 55 frequently forgotten or controversial facts and 10 fallacies of software engineering. The facts and fallacies contain a generous helping of useful advice that is both highly opinionated and well rooted in experience and research.

The book is an easy read, partly due to the highly structured content. Each of the 55 facts is presented in the same way: First, a short version of the fact is provided as a headline of sorts. Glass then delves into a more detailed description and discussion of the fact: What is it about, and why is it a fact? What kind of research supports this?

After the discussion, a section follows where he presents controversies. This is one of the main reasons I like this book: He actually elaborates on why people might disagree with him. However, it’s also the part of the book I’d most like to see improved. I don’t have a problem with these sections being highly opinionated – that’s just his style, and of course he isn’t going to just neutrally present the views of people he’s convinced are dead wrong. But while he often explains why those other people are wrong (according to research), he also sometimes just brushes them off without any further reason than “they’re wrong/​misguided”, and I’d like Glass to go into a bit more detail on these controversies.

Finally, after the controversy sections, Glass provides sources and references. These sections contain both academic and non-​academic sources (many from Glass himself, though that is to be expected given how relevant his research is in this context) and serve as jumping-​off points for further reading for the particularly interested reader.

Though I read the book from cover to cover, it can also be enjoyed by jumping around from fact to fact, or only reading the parts you’re interested in. Each fact stands on its own (though some consecutive facts are related to each other and only shine properly in light of each other), and you’re free to skip back and forth. The 55 facts are structured into chapters relating to software management (which I found highly interesting even as an inexperienced developer), the software life cycle (aspects of which can apparently be mistaken for religion at times), and software quality (in which Glass tries to delve into what actually constitutes good quality software, and what – in his opinion – it definitely isn’t).

Some examples

A reading of the table of contents (reproduced here) should give you a good idea about the topics of the book (though of course without any depth), but allow me to highlight a few facts anyway:

Fact 1: The quality of the programmers is much more important than the tools or methodologies they use. In light of the more recent “10x developer” concept, this may not seem that controversial. And indeed, Glass says that most people actually agree with this fact, yet the subtle controversy here is that most people keep behaving as it’s not true. Perhaps that’s because people are a harder problem to address than tools.

Another widely known fact is Fact 3: Adding people to a late project makes it later. This is included in the book because, as with Fact 1, it’s frequently ignored even though it’s widely known. Another fact in the same category is Fact 6: New tools and techniques cause an initial loss of productivity (which is also well known, but consistently undermined by the people selling the new tools and techniques).

Glass also provides several salient facts about error removal, reuse, and software quality, and some particularly insightful (in my inexperienced opinion) facts about software maintenance. For example, Glass holds that maintenance is not a problem to be defeated – it would only be a problem if nearly all of maintenance were about fixing errors, which it isn’t (fully 60% of maintenance is enhancements, according to research he cites). Instead, Glass says, maintenance is a solution – specifically, software’s unique solution to the problem “we built this thing, now we wish we had built something a little different.”

He ends the book with 10 fallacies – things that may seem like facts, but are in fact not (according to Glass and the research he cites). Examples include “you can’t manage what you can’t measure”, “software needs more methodologies”, and the open source mantra “given enough eyeballs, all bugs are shallow”.

Again, even though several of the facts and fallacies may be well known, all of them have some degree of controversy, whether they’re just easily forgotten or overlooked, accepted but with no consensus on how to fix it, or highly contented by the industry at large or its vocal gurus. (Interesting note: Glass defines “gurus” as “people known for their prominently expressed opinions”.)

In spite of all the possible controversy, I found myself easily agreeing with almost all of his points. That most likely speaks to my lack of experience – I have yet to be “tainted” by (what Glass considers to be) common malpractices and delusions of software engineering. I’ll just have to keep Glass’s opinions in mind, be open to other takes on these facts and fallacies, and make up my own mind as I gain more experience.

Conclusion

In summary, I found Facts and Fallacies of Software Engineering a highly rewarding read. The opinionated tone might deter some readers, but that’s their loss – the facts are far from unfounded. The book has certainly helped me along in my quest to become a more mature developer, and without a single line of code at that. Others might find most of it obvious and not get much out of it, or they might disagree with much of what he says (in that case, I would be interested in hearing the reasons behind those opinions). But considering that this book is on several experienced developers’ list of classics, I’m not afraid to recommend this to inexperienced and experienced practitioners alike.

---

Cover image: Unknown origin, found from this image search.