3 ms·

The kind argued to be the result of crazy edge cases or super weird conditions cannot. Not in the same absolute fashion. I'm not saying that you can't find or

The kind argued to be the result of crazy edge cases or super weird conditions cannot. Not in the same absolute fashion. I'm not saying that you can't find or avoid bugs, or build test suites to catch the majority. But the ones you don't catch have a lot more potentially random results.

jbri 16y ago
You're not a Formal Methods guy, I see.
streeter 16y ago
The Halting Problem (http://en.wikipedia.org/wiki/Halting_problem http://en.wikipedia.org/wiki/Halting_problem) talks about this. For individual algorithms, one can determine if it will halt or not. However, no general algorithm exists. The hard part is that the algorithm to cause the code to halt has to be specially crafted for every algorithm.
- Retric 16y ago
  The Halting Problem can be sidestepped by having a system say "I don't know" in edge cases. So it's possible to write code that can classify code as "safe" even if it misses some "safe" code that's more complex than it can handle.
HeyLaughingBoy 16y ago
There is no "absolute fashion" of avoiding bad conditions in any discipline of engineering. There are just different modes of failure that need to be considered. In the case of software, you would start with a Hazard Analysis. Designs/code that have high hazard (failure may mean serious injury or death for example) get more scrutiny and better protection. A simple example might be you that have to make a complex calculation that could be catastrophic if it is buggy. That might be mitigated by breaking up the calculation into segments and error checking each segment (e.g., protection against divide by zero deep inside the equation if the wrong set of parameters are input), or by having an additional sanity check on the value that's about to be output to an actuator given current conditions. The point here is to acknowledge that an unseen defect may be lurking in the code, and to try to add protection against it. There are also predictive techniques that a lot of groups use to estimate defect density. If you expect (based mainly on history) that there will be 1 defect/kLoC found in final test and the test team is only finding 0.1 or they're finding 10, then you need to go back and figure out if the estimates are wrong, the design is screwed up, or the testers are slacking off. In any case, the process should be adjusted. I don't know when software development will get to the statistically predictable state of modern manufacturing, but it will happen eventually. At least in the bits that are important enough.

jbri 16y ago

You're not a Formal Methods guy, I see.

streeter 16y ago

The Halting Problem (http://en.wikipedia.org/wiki/Halting_problem http://en.wikipedia.org/wiki/Halting_problem) talks about this. For individual algorithms, one can determine if it will halt or not. However, no general algorithm exists. The hard part is that the algorithm to cause the code to halt has to be specially crafted for every algorithm.

Retric 16y ago
The Halting Problem can be sidestepped by having a system say "I don't know" in edge cases. So it's possible to write code that can classify code as "safe" even if it misses some "safe" code that's more complex than it can handle.

HeyLaughingBoy 16y ago

There is no "absolute fashion" of avoiding bad conditions in any discipline of engineering. There are just different modes of failure that need to be considered. In the case of software, you would start with a Hazard Analysis. Designs/code that have high hazard (failure may mean serious injury or death for example) get more scrutiny and better protection. A simple example might be you that have to make a complex calculation that could be catastrophic if it is buggy. That might be mitigated by breaking up the calculation into segments and error checking each segment (e.g., protection against divide by zero deep inside the equation if the wrong set of parameters are input), or by having an additional sanity check on the value that's about to be output to an actuator given current conditions. The point here is to acknowledge that an unseen defect may be lurking in the code, and to try to add protection against it. There are also predictive techniques that a lot of groups use to estimate defect density. If you expect (based mainly on history) that there will be 1 defect/kLoC found in final test and the test team is only finding 0.1 or they're finding 10, then you need to go back and figure out if the estimates are wrong, the design is screwed up, or the testers are slacking off. In any case, the process should be adjusted. I don't know when software development will get to the statistically predictable state of modern manufacturing, but it will happen eventually. At least in the bits that are important enough.