4 ms·

Short answer: No. After studying state estimation and control systems, I'm in no way surprised that there are this many lines of code in a system. I also am n

Short answer: No. After studying state estimation and control systems, I'm in no way surprised that there are this many lines of code in a system. I also am not scared of it. This is how I think about it: Bugs in control systems code are often not visible until some super-weird edge case or some extreme condition is hit. In this case, it's probably too late for the software to really do anything to help you. If it does help, great, if it wasn't there, you'd be screwed anyway. Bugs that affect normal and slightly abnormal operations are very obvious. Essentially, I'm no more worried about the LOC count in my car than I am about a micro-fracture in a bolt that holds my brakes on.

mrcharles 16y ago
And yet, something like a stress fracture can, within reason, be predicted using scientific models, where software bugs cannot. Or at least, their results cannot be predicted.
- Bud 16y ago
  Software bugs can never be predicted? And results and failure modes can never be predicted? I disbelieve.
  - mrcharles 16y ago
    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.
- jacques_chester 16y ago
  > And yet, something like a stress fracture can, within reason, be predicted using scientific models, where software bugs cannot. What do you suppose type systems are doing? A lot of the time they're proving that something is wrong with your code. AT&T also did some very comprehensive studies that demonstrated you can predict, with a surprising amount of confidence, which modules of a system will continue to manifest the most bugs, based on existing reports.
- starpilot 16y ago
  I'm an aerospace stress analyst. I doubt there is significantly more predictability in mechanical failures than there is in software failures. With physical parts, there's theory, but it's still up to the human engineer to apply the theory and understand it correctly. In my field, a case study might be the de Havilland Comet, the first jetliner. Initial versions featured windows with sharp corners. The structure failed at those points because of stress singularities formed at sheet corners. Was the theory of stress concentration factors new? No. But trained engineers overlooked a design aspect that failed. They knew the science, but didn't know to implement it correctly. The exact type of oversight occurs in software engineering as well. (And now you know why all jetliners today have rounded windows.)

mrcharles 16y ago

And yet, something like a stress fracture can, within reason, be predicted using scientific models, where software bugs cannot. Or at least, their results cannot be predicted.

Bud 16y ago
Software bugs can never be predicted? And results and failure modes can never be predicted? I disbelieve.
- mrcharles 16y ago
  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.
jacques_chester 16y ago
> And yet, something like a stress fracture can, within reason, be predicted using scientific models, where software bugs cannot. What do you suppose type systems are doing? A lot of the time they're proving that something is wrong with your code. AT&T also did some very comprehensive studies that demonstrated you can predict, with a surprising amount of confidence, which modules of a system will continue to manifest the most bugs, based on existing reports.
starpilot 16y ago
I'm an aerospace stress analyst. I doubt there is significantly more predictability in mechanical failures than there is in software failures. With physical parts, there's theory, but it's still up to the human engineer to apply the theory and understand it correctly. In my field, a case study might be the de Havilland Comet, the first jetliner. Initial versions featured windows with sharp corners. The structure failed at those points because of stress singularities formed at sheet corners. Was the theory of stress concentration factors new? No. But trained engineers overlooked a design aspect that failed. They knew the science, but didn't know to implement it correctly. The exact type of oversight occurs in software engineering as well. (And now you know why all jetliners today have rounded windows.)