Hacker News Reader

Comment by eternalban | Hacker News Reader

Not sure this can be called a "bug". This was a design error.

Bugs are found in many different places in software (or hardware). Some examples that come to mind,

  1. Design
  2. Implementation
  3. Configuration
  4. Deployment

I'm sure other people might think of some more.

I've encountered Requirements bugs due to the requirement being flat out wrong. Those are usually easy to find. Contradictory ones can hide until you try to implement them.

But one of my favorite tricky ones was an apparently very clearly written Requirement. It passed all the Requirements reviews, design passed design review, code passed, etc. Then the original writer of the requirement went to use the product and said "but that's not what I meant" Sure, I implemented exactly what he very clearly said (wrote) but that turned out to be very different from what he meant to say.

If all bugs were in code my job (as a programmer) would be so easy.

It's all the squishy human-worded requirements that cause the problems.

Maintenance too. Faulty maintenance routines can break stuff, anybody who's got a car knows that very well.

Design errors are bugs. They're some of the deepest and most difficult to fix, in no small part because someone meant for it to be that way.

A site that's falling over or won't load is obviously broken. One whose design subtly invites bad behavior may not be immediately evidently broken. But it's broken all the same.

I'd agree.

A website failing due to too many users is not a bug, it's a design issue.

And remembering we both build buildings and programs acknowledging they can catastrophically fail under certain possible real world conditions, but we only minimise it.

Here they accidentally didn't minimise the failure rate enough.

Plus if it never failed in testing or real life, was it even a bug?

There's no proof they were right and it would have failed. Lots of other fails safes might have come into play.

Definitely not a bug.

Plus if it never failed in testing or real life, was it even a bug?

Yes. I have proven that we shipped software with a bug that can crash the system given a very likely set of inputs. The fact that we never saw that particular combination of inputs was sheer dumb luck due to how it was most commonly configured.

I still call that a bug: if a user does X, where X is a reasonable thing to do, I guarantee the system will crash. That no user has done X yet does not mean it's not a bug.

It's clearly not just a design error. A conscious design decision was made: build the building with supports in the middle of the sides instead of the corners. This, in and of itself, was not a bug. In addition, a conscious implementation decision was made: hold the thing together with bolts instead of welds. Similarly, this alone was not a bug.

The two taken together hit a corner (heh) case and give rise to a bug.

The author says why he uses the term "bug":

> The reason I call this engineering fault a "bug" is that it arises the same way other bugs do.

they built something to take a particular input (hurricane-force winds) and produce a specific output (keep standing). Their calculations and over-engineering led them to expect that output all the way through production. Further investigation revealed that another output was more likely. I call that a bug.

Reply on news.ycombinator.com