Hacker News Reader

Comment by Morendil | Hacker News Reader

Amusing exchange over at Reddit:

Redditor 1: "I bet not a single f$%k was given about that table among the readers of the book :)"

Redditor 2: "That table, or something like it, features strongly in every software engineering textbook that I've ever seen. The numbers differ, but the increasing order of magnitude differences are roughly the same. It's the essential justification for nearly everything in software engineering. "A single f$%k" doesn't begin to describe the importance of that table."

And yes, "the essential justification for nearly everything in software engineering" is broadly correct. Anytime you see an argument that "it's important to get the requirements right" for instance, it's based on studies that purport to show these numbers.

View on HN

Indeed, with the semantic cavet that "software engineering" is used in the sense of "software development management process nattering" and not (always) the actual engineering of working software.

The basic falseness of that chart is pretty well known among the hacker set. Or maybe it's a failure of interpretation among the natterers: the "high cost" of mistakes in the past is made mostly of work already spent. The immediate cost of correcting a past mistake is often (of course not always!) vastly lower than people think. And the farther you are from the actual code involved (i.e. if your role is "architect"), the higher your overestimate of that value is going to be.

So this is a feedback loop: the "high level" people at the start of the process have a built-in bias against iterative solutions (which they perceive as "expensive") and thus a built-in predilection to overdesign as they try to get everything right the first time.

I'm glad someone else sees the difference between the engineering of working software and the "process nattering" that seems to make up official "software engineering" as far as I can tell.

You do miss a couple of steps in the feedback loop:

1. "The 'high level' people at the start of the process have a built-in bias against iterative solutions."

2. "A built-in predilection to overdesign as they try to get everything right the first time."

3. The wild-ass guesses that make up the overdesign prove to be completely wrong.

4. The project fails miserably or succeeds, miserably.

5. The "high level" people perceive software as "very expensive", reinforcing their biases.

>"it's important to get the requirements right" for instance

Well, we've all been there. If you don't get them right, it will really hurt. A lot.

Also, moving things in a wireframe or diagram around is basically free whereas moving things around in a "finished" product can be fairly time consuming.

So, there is at least some truth to it.

Reply on news.ycombinator.com