Frequently Forgotten Fundamental Facts about Software Engineering

Robert Glass writes consistently interesting stuff, and this was no exception.<p>I wish he had a higher profile (similar, say, to Spolsky and Atwood, for example)....

This article is really crying out for footnotes. It cites a lot of studies and facts, but provides no references at all.

From now on I'll show this:<p><i>RES1. Many software researchers advocate rather than investigate. As a result, (a) some advocated concepts are worth less than their advocates believe and (b) there is a shortage of evaluative research to help determine the actual value of new tools and techniques</i><p>to a researcher friend of mine every time he advocates the use of Lisp in commercial projects claiming that such a great language will just inevitably bring more productivity to the team in comparison with such a poor language like Java (or any other Blub.)

Wow. I feel like I need to go smoke a cigarette after reading that list. I also want to print off 10,000 copies and throw them like confetti around several of my previous jobs.<p>"in a room full of expert software designers, if any two agree, that's a majority!"

<i>"P2. Good programmers are up to 30 times better than mediocre programmers, according to "individual differences" research. Given that their pay is never commensurate, they are the biggest bargains in the software field."</i><p>P3. Good programmers are defined as those programmers that produce good products. If you focus only on coding speed or analytical skill, you may miss out on the best programmers.<p>P4. If you are paying your good programmer less than you know s/he is worth, count on them leaving soon. You will deserve the loss.

I'd like to highlight this particular gem:<p><i>RE4. Even if 100-percent test coverage (see RE3) were possible, that criteria would be insufficient for testing. Roughly 35 percent of software defects emerge from missing logic paths, and another 40 percent are from the execution of a unique combination of logic paths. They will not be caught by 100-percent coverage (100-percent coverage can, therefore, potentially detect only about 25 percent of the errors!).</i><p>Given the fanaticism for TDD today, this is a fact well worth remembering.

I agree with the general thrust, but can we avoid pseudo-numeric language, like "for every 10% increase in $NEBULOUS_THING_PROGRAMMERS_FIND_ANNOYING, $HARD_COST_NUMBER goes up by 100%". Really, we can do better.<p>There was an article about this on HN a while back, but I can't find it right now.

He gives a summary here of good points. He has often given very practical advice about software engineering.<p>However, a minor quibble: <i>REU2. Reuse-in-the-large (components) remains largely unsolved, even though everyone agrees it is important and desirable.</i> Not everyone agrees about reuse-in-the-large as being desirable. In Coders At Work, Knuth goes so far as to suggest taking apart other "reusable" libraries and rewriting them. Rumbaugh (of the Three Amigos) has said that reuse-in-the-large is overrated as a goal.

The estimation section really hit home for me.<p>It seems like the harder we try to improve estimate accuracy the worse it gets. Are there any great examples of successful software estimation?

Yep, I'm only going to pay attention to the ACM's stuff rather than IEEE. Look at the obsession with percentages and pseudo-mathematical formulas like this: "User satisfaction = quality product + meets requirements + delivered when needed + appropriate cost."

You gotta love forced alliteration!

"I don't expect you to agree with all these facts; "<p>Well, not unless you provide links to references.<p>In fact, here's one fact that was left out: merely asserting something in a technical article does not make it a fact. It's opinion until you back it up with data.