Revisiting The Facts and Fallacies of Software Engineering

I like to re-read my favorite books every few years, so I brought Robert Glass' seminal Facts and Fallacies of Software Engineering with me on my most recent trip. I thought it was a decent, but imperfect read when I originally bought it in 2004. As I scanned through the introduction and table of contents, I realized that I've written about almost everything in this book by now.

This is a companion discussion topic for the original blog entry at:

You’d do good to write a post detailing your top book purchases of all time :slight_smile:

“I realized that I’ve written about almost everything in this book by now.”

Yes, you HAVE pasted other people’s thoughts on all of the subjects covered in this wonderful book. And then linked to your old posts about the exact same things over and over again.

Fantastic book. I really enjoy Robert Glass’ writing. Here is a guy who doesn’t jump into the hype machine. Everything is clean and balanced and forces you to think about what he says. I also enjoy his columns in the Communications of the ACM. His column is always the first page I read.

Heh… No. 7 brought me a smile xD

  1. Software developers talk a lot about tools, but seldom use them.

wow, i’m impressed!

This has piqued my curiousity…

  1. COBOL is a very bad language, but all the others are so much worse.

Can anyone who’s read the book elaborate?

Agreed… Jeff, would you consider updating your must-read/all-time-favorite book list?


Reading this table of contents actual depressed me in some ways. I must have read a half dozen books that cover the contents and they all ring true, but the frustrating part is the effort it takes to work on any issue when the majority of your company doesn’t share the same view.

To me this table of contents is a great bullet point list that non-software engineers should read. I personally work in the games industry and I think that many of the other disciplines (art, design and management) really don’t understand anything about building software. Some of them have been doing it for years but I don’t think they realize the truth of the statements in the list.

It kind of reminds me of a comment one of my friends made at work about STL code. We both love it but we realize that you have to code to the lowest common denominator of education to have a reusable and maintainable code base. Maybe our game studio is a bit in the dark ages in not pushing people to learn these new skills, but I find this table of contents a similar kind of problem where if other people in my company do not get creating software (an example would be only budgeting 20% of the software cycle for bug fixing and no maintenance budget at all) it just makes me want to stop reading and start fixing things with what I know already.

To end this long rant, perhaps this is something I would add to the list:
“Many engineers know more about software management than their managers, few of them want anyone to find out they do lest they will have to manage”

I’ve never read the book, but I’ve probably crawled through every post on this Blog looking for useful tidbits to bring to my student life. It’s shocking how little students are taught about these very issues you write about, and I’m grateful to you for doing so.

Regardless, I will definitely be purchasing this book.

“Yes, you HAVE pasted other people’s thoughts on all of the subjects covered in this wonderful book. And then linked to your old posts about the exact same things over and over again.”

Ah, I see; Jeff’s blog sucks. Why are you commenting then? Don’t you have better things to do?

I too am interested in #30.

I am buying the book, I have yet to be steered wrong about a recommendation here.

Jeff, I have been a software professional for 17 years now and can attest to (and have experience with) almost everything Robert Glass (and other authors have been extolling for years) says in his Facts and Fallacies.

However, I have a bone to pick with you – it is your usage of the word “craft.” Software engineering and craft do not mix. Jeff, I think you are doing a disservice to our industry. Software engineering is just that – an engineering discipline. In fact, here in British Columbia, Canada, you can become a Professional Software Engineer, complete with a P.ENG designation and be legally liable for the designs and code we produce -

I believe thinking about software engineering as a “craft” is yet another fallacy of our business. I work with electronics and mechanical “engineers” who laugh at our UML stickman and the like – and for good reason – its embarrassing man! We are so unindustrialized!

Instead of re-reading what we already know about our industry, why aren’t we actively doing something about it? Particularly you Jeff – you command a huge audience – you can have a major influence on what people do in our industry. Don’t have them just read (btw, you might want to go right back to the roots of software engineering - ) about software engineering – get them to actively do some software engineering!

Mitch, I really like your point:
“Software engineering and craft do not mix. Jeff, I think you are doing a disservice to our industry.”

However, I have a bone to pick with this as well and it is mostly about scale of development. I personally don’t believe that most software needs engineering. I think it is ridiculous that people use the term software engineering for what is essentially construction work. I think that we have a lot of work that needs doing by people that know the basics of coding. I think you will see small, very well written applications by software craftsmen that are the peak of this industry and I think that we need software architects and software engineers to build systems that are more complicated and need long term vision and support. I think all of these terms are applicable and the issue is that a manager can’t tell a software construction worker from a crafts person or an engineer.

So…I agree that we should push for software engineering to be an actual engineering profession, but I think we should allow the language an niches for those that fit the other descriptions.

Out of interest, being legal liable for code - how do you deal with the 2% (or something around there) cases where the code outside of your own may cause a catastrophe? I always wonder what that is like since I work in an industry where we depend on numerous technologies that aren’t “engineered” and I cannot picture signing off on code I never reviewed.

True. Thanks for an advice and your post.

I’ve been accused of gratuitous self-linking in the past

Aw man. I like the self-linking. I guess people who’ve been regular readers for years (and have really good memories) might find it annoying, but to me it’s the perfect way to get introduced to your archives: articles relevant to the one I’m reading now.

Why do people keep having the stupid debate about is programming engineering, art, craftsmanship, whatever? It’s not important in the least, just call it software development, or programming, and leave the question of which discipline it falls under alone.

Nice post! I’ve read some ob Robert Glass’ books, but not this one. I may have to have it.

I would like to add to the list of good books suitable for all software engineers is Gause, Weinberg, “Exploring Requirements: Quality Before Design”. This book was very influential for me. It changed some of what is now my Personal Software Process.

Another favorite way back when: Allan Holub, “Enough Rope to Shoot Yourself In the Foot”. Specifically on programming technique. Focused on C/C++. It’s been a while.

heh, wish I had thought of this earlier when I was composing my first comment.

“The quality of a software product is a direct function of the process used to produce it.” – Weinberg (I think). Anyway, it is a good rule of thumb.

Producing software that only I will use takes effort 1.

Producing software that others will use where those others will always have personal access to me takes effort 10.

Producing software that others will use where those others will never have personal access to me takes effort 100.

Better methods lead to more maintenance, not less.

Could this be Jevons paradox at work? I am not sure. What do you think?

One way to understand the Jevons Paradox is to observe that an increase in the efficiency with which a resource (e.g., fuel) is used causes a decrease in the price of that resource when measured in terms of what it can achieve (e.g., work). Generally speaking, a decrease in price of a good or service will increase the quantity demanded (see supply and demand, price elasticity of demand). Thus with a lower price for work, more work will be “purchased”. This increase in quantity demanded may or may not be large enough to offset the original efficiency gain.

In the country where I studied, Software was a part of the Engineering dept. There was no Computer Science, as such, all engineers had to spend 2 years taking the same foundational courses, no matter if they wanted to be an Industrial or Software engineer.

Looking back at it, I’d say those first 2 years were the most important, as any real software developer studies programing on their own during their entire career and probably even before going to school.