3 ms·

Bug-free is more about how narrow the spec is. Can your GUI app works on a Windows 95 with Polish as the system langauge while using a Chinese input method, an

Bug-free is more about how narrow the spec is. Can your GUI app works on a Windows 95 with Polish as the system langauge while using a Chinese input method, and the user holding Alt all the time? Probably not. But the question we should ask isn't how could we make it work, but why the hell do we need to support this use case?

lelanthran 3y ago
> But the question we should ask isn't how could we make it work, but why the hell do we need to support this use case? I don't even think it is necessary to ask that question. The only question that should be asked for something like this is "How do we handle all unsupported use-cases?" Because then it becomes simpler, when an edge-case causes the software to freeze, to detect for that edge-case and hand it off to the "not supported" handler. In the best case scenario, we simply detect whether the use-case is supported and then either proceed or hand control to the not-supported-handler. In the worst case scenario, when the bug report comes in, we don't even bother trying to reproduce it, we just add a general check for it and move on to the not-supported-handler. In this particular case, the detection can do any one of the following: 1. Check for english, and if not, display "unsupported language". 2. Check that input language and system language match, or display unsupported". 3. Check that the OS is supported, display "unsupported OS" if not. 4. Check that the input is valid (i.e. no special codes, whether by holding down halt or otherwise), or display "unsupported input". Whether the spec is narrow or wide, the developer needs to do the work to ensure that the user is running within spec. Not checking results in more "bugs" that are, as you said, use-cases which shouldn't be supported anyway.
- pixl97 3y ago
  >"How do we handle all unsupported use-cases?" Until you find out that your operating system handles 95% of unsupported cases in one way, then uses a hidden API to deal with the weirdness of other languages and the unsupported case isn't detected in that last 5% of languages. Of course that never came up in testing because who uses a hebrew/japanese combination and now the error message being returned by your application has nothing to do with the actual problem. Your worst case scenario is just the common edge case bug handling that support/QA/dev's handle every day.

lelanthran 3y ago

> But the question we should ask isn't how could we make it work, but why the hell do we need to support this use case? I don't even think it is necessary to ask that question. The only question that should be asked for something like this is "How do we handle all unsupported use-cases?" Because then it becomes simpler, when an edge-case causes the software to freeze, to detect for that edge-case and hand it off to the "not supported" handler. In the best case scenario, we simply detect whether the use-case is supported and then either proceed or hand control to the not-supported-handler. In the worst case scenario, when the bug report comes in, we don't even bother trying to reproduce it, we just add a general check for it and move on to the not-supported-handler. In this particular case, the detection can do any one of the following: 1. Check for english, and if not, display "unsupported language". 2. Check that input language and system language match, or display unsupported". 3. Check that the OS is supported, display "unsupported OS" if not. 4. Check that the input is valid (i.e. no special codes, whether by holding down halt or otherwise), or display "unsupported input". Whether the spec is narrow or wide, the developer needs to do the work to ensure that the user is running within spec. Not checking results in more "bugs" that are, as you said, use-cases which shouldn't be supported anyway.

pixl97 3y ago
>"How do we handle all unsupported use-cases?" Until you find out that your operating system handles 95% of unsupported cases in one way, then uses a hidden API to deal with the weirdness of other languages and the unsupported case isn't detected in that last 5% of languages. Of course that never came up in testing because who uses a hebrew/japanese combination and now the error message being returned by your application has nothing to do with the actual problem. Your worst case scenario is just the common edge case bug handling that support/QA/dev's handle every day.