5 ms·

IMO, if the defect is because some functionality wasn't specified and there's an edge case, that's not the programmer's fault. OTOH, if the required functional

IMO, if the defect is because some functionality wasn't specified and there's an edge case, that's not the programmer's fault. 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.

jgwil2 6y ago
If functionality wasn't specified, then it's not a defect, it's working as expected.
- iimblack 6y ago
  Unfortunately many companies don’t differentiate.
- greenyoda 6y ago
  Some functionality should be common sense to a competent developer, and not have to be specified. As a developer, I'd expect working code to have the following behavior, whether or not it was explicitly written into the spec: - 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.
- virgilp 6y ago
  "working as expected" doesn't preclude defects. As expected by whom? There's always a range of expectations to consider... take the iPhone4 antenna, was it a bug or just people "holding it wrong"/ intentionally squeezing the phone to demonstrate signal loss? Or, take programming languages - is the null pointer "working as expected", or is it a "billion dollar mistake"?
T-hawk 6y ago
I like to use this phrase for this sort of thing: "It's working as designed but the design was flawed." 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.
chooseaname 6y ago
> some functionality wasn't specified and there's an edge case 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.
- gowld 6y ago
  Edge cases are common. Corner cases are rare.
  - eindiran 6y ago
    I'm not familiar with this distinction: what is the difference you're pointing to here?
    - gowld 6y ago
      Take a look at polytope. Edges are easier to hit than corners. If you start in a random place and move in any direction, you will eventually hit an edge. But you might never hit a corner.
    - eindiran 6y ago
      In case anyone was wondering the actual definitions: 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] [0] https://en.wikipedia.org/wiki/Edge_case https://en.wikipedia.org/wiki/Edge_case [1] https://en.wikipedia.org/wiki/Corner_case https://en.wikipedia.org/wiki/Corner_case

jgwil2 6y ago

If functionality wasn't specified, then it's not a defect, it's working as expected.

iimblack 6y ago
Unfortunately many companies don’t differentiate.
greenyoda 6y ago
Some functionality should be common sense to a competent developer, and not have to be specified. As a developer, I'd expect working code to have the following behavior, whether or not it was explicitly written into the spec: - 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.
virgilp 6y ago
"working as expected" doesn't preclude defects. As expected by whom? There's always a range of expectations to consider... take the iPhone4 antenna, was it a bug or just people "holding it wrong"/ intentionally squeezing the phone to demonstrate signal loss? Or, take programming languages - is the null pointer "working as expected", or is it a "billion dollar mistake"?

T-hawk 6y ago

I like to use this phrase for this sort of thing: "It's working as designed but the design was flawed." 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.

chooseaname 6y ago

> some functionality wasn't specified and there's an edge case 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.

gowld 6y ago
Edge cases are common. Corner cases are rare.
- eindiran 6y ago
  I'm not familiar with this distinction: what is the difference you're pointing to here?
  - gowld 6y ago
    Take a look at polytope. Edges are easier to hit than corners. If you start in a random place and move in any direction, you will eventually hit an edge. But you might never hit a corner.
  - eindiran 6y ago
    In case anyone was wondering the actual definitions: 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] [0] https://en.wikipedia.org/wiki/Edge_case https://en.wikipedia.org/wiki/Edge_case [1] https://en.wikipedia.org/wiki/Corner_case https://en.wikipedia.org/wiki/Corner_case