Robert L. Glass wrote a book in 1998 called “Software 2020”, currently rated with only one star… by the author himself. In his review (written in 2017) he justifies this abysmal record because of a simple observation: none of the predictions in the book turned out to become a reality.
On the other hand, “Facts and Fallacies of Software Engineering”, published in 2003, has four stars out of five on Amazon. This opus, then, clearly outperforms the previous title by the same author. Maybe this success is due to the fact that, unlike its predecessor, this book does not predict the future; instead, it describes an eternally grim present, one that never seems to go away, no matter how many new versions of your debugger you try.
Because, let us be honest. Reading this book is pure masochism. Not because it is badly written (far from that) or that the contents are not relevant. Quite the opposite, actually; the sad truth of our craft is described in painful detail in every single section. Reading it is an exercise in nodding.
This book has received its fair share of reviews, slashdot threads, and discussions. No need to indulge the reader into yet another discussion of the relative merits of each section, or whether or not the author agrees with each item. That is utterly irrelevant.
The core question raised by this book, re-reading it in Anno Domini 2021, is why is our industry still falling into the same traps? Why do managers keep considering lines of code as a valuable metric (fallacy 6)? Why is it that companies need to continuously break backwards compatibility in their SDKs and IDEs (fact 6)? Why are schools not properly training younger developers to the reality they will face during their careers (fact 48 and fallacy 10)? Why is it that full-stack developers feel an urge to dive every year into the newly hyped JavaScript framework du jour (fact 5)? Why are not product owners aware of the increase in complexity of every new feature added to the backlog (facts 21 and 23)? Why do some companies insist in 100% test coverage, even though it is not useful nor enough (fact 33)? Why do we keep on insisting on cramming developers in open space offices (facts 4 and 13)? Why do many teams still not adopt healthy code review practices (fact 37)?
Why is it that our craft is such a disgusting mess of appalling whimsical cargo-cult practices, disguised as perfectly coherent and rational ideas? A deep sigh ensues.
Not being able to resist the temptation, this author will briefly mention one fact and one fallacy to start reading:
- Fact 30: COBOL is a very bad language, but all the others (for business data processing) are so much worse.
- Fallacy 8: “Given enough eyeballs, all bugs are shallow.”
This book can be read in a fully non-linear fashion, so feel free to explore this classic starting with these two. Think of this book as a guide, providing answers for most questions (almost all, I would say) you are going to have about your craft, your teams, and your code, for years to come.
As a personal wish, the author of these lines can only hope for a future in which our craft will work on each of these facts and fallacies, and work towards fixing them in the long run.
Cover photo by the author.
