That's pretty successful at getting the business/product people off the blame-assigning game and thinking productively towards resolving the interaction and defining a solution.
- If the credit card transaction fails, do not ship the product to the customer, and notify the customer of the failure.
- Don't let the customer order more items than are available in our inventory, or zero items, or a negative or non-integer number of items.
- A web-based system should correctly handle multiple concurrent transactions.
- If something goes wrong, show the user a meaningful error message in their selected language, not a Python stack trace.
If my excuse for my code not doing this was "it wasn't in the spec", I'd expect people to ridicule me.
Or, take programming languages - is the null pointer "working as expected", or is it a "billion dollar mistake"?
Edge cases are extremely rare. If they weren't they'd not be an edge case. But, we should still try and build robust systems and not allow the system to be in an unknown state. It isn't, "I have to think of all the possible cases." No, it's "These are the possible cases, nothing else is allowed."
If the cases were not specified, as you mention, then that is not completely a dev issue.
An edge case is a problem or situation that occurs only at an extreme (maximum or minimum) operating parameter. For example, a stereo speaker might noticeably distort audio when played at maximum volume, even in the absence of any other extreme setting or condition. [0]
A corner case (or pathological case) involves a problem or situation that occurs only outside of normal operating parameters—specifically one that manifests itself when multiple environmental variables or conditions are simultaneously at extreme levels, even though each parameter is within the specified range for that parameter. [1]
OTOH, if the required functionality is documented and it doesn't work, that is the programmer's fault.
> A lot of the nastiest bugs come from components that are all correct in isolation but interact in a dangerous way. This is called a Feature Interaction Bug.
IMO, the original programmers of those components are not at fault, but if someone uses those components together and doesn't verify that they're working as desired, that "someone" is at fault.
Sure, stricter discipline won't always help, but sometimes it will. Sometimes, the programmer really is just being lazy.
And I say this as a programmer.