4 ms·
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 error
by ChrisMarshallNY 2y ago
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 2y agoCorrect. 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 2y agoAnyone 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.”