[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.”