[pyfon]

Errors often come from the fact that we build on unreliable medium.

Lost packets, high latency, crashed disks, out of memory etc.

You can talk to your users sure but you need to handle this stuff at some level either way. Shit happens!

[ChrisMarshallNY]

Absolutely.

But we need to plan for it from Day One, and that can also include things like choosing good technology stacks.

Like I said, when inevitable errors happen, how we communicate (or, if possible, mitigate silently) the condition, is crucial.

[EDITED TO ADD] Note how any discussion of improving Quality of software is treated, hereabouts. Bit discouraging.

[pyfon]

Correct. What errors can happen PLUS how we communicate (and what we do: roll-back transaction? Etc.) PLUS how do we ensure correctness of both (sane programing language, good idioms, testing, proofs etc.)

[ChrisMarshallNY]

Anyone that has maintained a shipping product, can relate to this.

Often, there is disagreement over the definition of “bug.”

There’s the old joke, “That’s not a bug, it’s a feature!”, but I have frequently gotten “bug reports,” stating that the fact that my app doesn’t do something that the user wants, is a “bug.”

They are sometimes correct. The original requirements were bad. Even though the app does exactly what it says on the tin, it is unsuitable for its intended demographic.

I call that a “bug.”