Facts and Fallacies of Software Engineering
So I’ve just graduated from university. No longer having that on my mind, I’ve taken the opportunity to take a step back and have a look at what’s important for me to be working on over the longer term. One of the things that I feel I should be doing is to ensure that I continue reading and learning autonomously while I’m out of educational institutions. Idea being, if I learn just a little more with each new day, I might wake up one morning (or afternoon) and find that I’m not half bad at this whole software thing (or just suck less). Label it self-betterment if you like, but I promise running over hot coals won’t become a part of my repertoire (or at least if it does, I’ll destroy all evidence of this post).
Back at university I was kept well busy with plenty of prescribed texts to read. I also made time to read a few other non-prescribed texts, but never as many as I would have liked. Now that I’ve got some time, I’m making a point of reading some of the other software texts that have been on my “to read” list for quite some time. As I make my way through these books, I’ll voice my thoughts on them here. Anyway, the book which I’ve just finished reading (or victim #1) is Facts and Fallacies of Software Engineering by Robert L. Glass.
I heard about this book a while back. It sounded like an interesting enough read so I grabbed a copy.
So what is there to be had out of this book? Well, as you might have guessed, or at least been hoping, there are some interesting facts (and fallacies) about software engineering contained within. When talking about facts, here’s the overarching topics the text discusses:
- People
- Tools and Techniques
- Estimation
- Reuse
- Requirements
- Design
- Coding
- Error Removal
- Testing
- Reviews and Inspections
- Maintenance
- Quality
- Reliability
- Efficiency
- Research
Most of the facts in each of these sections are rules of thumb; “generally speaking” type statements. A few quick example facts:
Fact #3: Adding people to a late project makes it later.
Fact #31: Error removal is the most time-consuming phase of the lifecycle.
Fact #42: Enhancements represent roughly 60 percent of maintenance costs.
The facts take up the majority of the book; fifty-five facts in total. There’s only ten fallacies, which according to Glass are what many in the software engineering field believe to be true, but turn out to be false upon closer inspection. For example:
Fallacy #1: You can’t manage what you can’t measure.
Fallacy #6: To estimate cost and schedule, first estimate lines of code.
If you’d like an exhaustive list of the fifty-five facts and ten fallacies, then check out revisiting the facts and fallacies of software engineering.
I think my personal favourite fact out of this book was Fact #5: “Hype (about tools and technology) is a plague on the house of software”. It’s noted that most software tools and technique improvements actually account for about a 5 to 35 percent increase in productivity and quality, and yet at one point or another someone will invariably have touted “order of magnitude” benefits. Glass points out that the sources of such hype almost always have some form of vested interest, whether it be product sales, high-priced courses or research funding. Admittedly you could label me a hypocrite at this point, having linked that book cover to my Amazon associate sales account just a few paragraphs back. I’ll do my best to remain objective though, and I certainly won’t be claiming order of magnitude benefits from reading this single book.
The discussion of hype in fact five reminded me very much of a Ruby on Rails course I took at university. Even if it had have been the greatest thing since sliced bread, there was nothing like a bunch of dogmatic pseudo-cultured Mac user stereotypes to turn me off the product. Ruby on Rails as a technology was fine, but there’s only a certain amount of narcissism one can ingest. Strangely enough, it didn’t work half as easily for me as it did for the guy giving the paid seminars. For anyone who has ever gotten caught up in the hype of a technology or methodology, only to find yourself bitterly disappointed that it couldn’t in fact single-handedly cure cancer and eradicate poverty, then reading this book should make you feel somewhat better.
To be fair, and while on the subject of narcissism, I think Glass has easily earned the “most references to my own work” award with this book. The text seems to be laced with pointers to other books or journal articles that he has authored. Then again, the book does come across as somewhat of a summary of much of his earlier findings which makes the heavy self-referencing (or self-promotion?) a little more forgivable.
I’d like to kick back by the fire with a glass of whiskey and a cigar and reminisce about the good old days, noting how many age-old lessons and timely reminders are contained within Facts and Fallacies of Software Engineering. The problem is, I don’t smoke, I don’t have a fireplace and I’ve only been working in software for two and a half years (and as an undergraduate). With the new alcohol taxes in Australia, I probably can’t afford whiskey either. Anyway, you’ve probably deduced that I’m no portrait of experience. It’s therefore not my place to pontificate on how all this stuff is congruent with the last n decades of my professional career. Nonetheless, I did identify with some of the facts and fallacies in the book; a.k.a. lessons that I’ve already learnt the hard way. The other facts and fallacies I’ll keep in mind and see how well they align with my own experiences over the coming years.
All in all it was a pretty good read. It’s relatively short (224 pages) and is the kind of book that you can read away from the computer. You certainly won’t learn the quickest way to sort one million 32-bit integers and if that’s the level of technical detail your after then find another book (and don’t ask Barrack). Some might even say the book is a little too high level, without enough meat to it. You can at least be assured that there’s plenty of references to more detailed works (even if half of those works are the author’s own ink). If I had to compare it to a fairly popular yardstick, I’d say it’s like a Code Complete
Facts and Fallacies of Software Engineering is the kind of book that you don’t need to invest a lot of time in and one that you can pick up right where you left off if you find yourself interrupted. Because of this I found the book perfect for filling those sporadic segments of idle time that have a habit of creeping into my life. Still, it was interesting enough that I wanted to come back and continue reading it, even outside of those “idle” periods. For anyone that reads software engineering texts on a regular basis, I imagine that much of this book will come as old news. Still, it’s the kind of book that you’d want to read even as a refresher on everything you’ve learnt and forgotten about software engineering over the years.