News for hackers. Stuff that matters.
Re:What Should We Do to Prevent Software from Failing? by jandrewrogers on Monday May 20, 2019 @04:15PM (#19964669)
A key difference between physical engineering and software engineering is that the economics of over-engineering to improve safety margins are wildly different. For physical engineering, the costs of substantially decreasing failure risk (e.g. via increasing strength, different materials, more complex design, etc) is approximately linear. For software engineering, that cost is something closer to quadratic or worse.

This is intrinsic to the differing nature of the problems. Verifying the safety of a bridge design is computationally trivial, verifying the safety of non-trivial software is NP-Hard. Safety is so inexpensive to add in physical engineering designs that we invest a lot of effort removing incidental unnecessary safety.

Re:What Should We Do to Prevent Software from Failing? by Jtsummers on Monday May 20, 2019 @04:52PM (#19965069)
> verifying the safety of non-trivial software is NP-Hard.

While true, this depends very much on the design (or lack thereof) of the software system. Many of our software systems are more complex than necessary because they weren't designed or the designs weren't considered carefully enough. When the software is allowed to grow and accumulate masses of code virtually unchecked, it becomes computationally intractable to continue to verify the system.

Much of the software involved in aircraft, specifically, can be reduced to very simple designs and implementations where the necessary safety analysis is feasible.

The present complexity is often in the accumulation of legacy defects and corrections (fixing the right problem in the wrong place) or trying to fix hardware problems with software. I'm not 100% pro-rewrite, but many avionics software groups (that I've encountered) refuse any rewrites on certification grounds but end up with something unbearably complex as a result (simulating hardware databuses from the 1980s in software on a 1 GHz processor when the system was initially targetting a 16 MHz processor).

Re:What Should We Do to Prevent Software from Failing? by avmich on Monday May 20, 2019 @04:56PM (#19965104)
Try to solve an aerospace problem with this "simple" approach. No, you don't get to add strength willy-nilly, or just swap materials on a hunch. You're working with safety factors which sometimes are less than 1 (come back for references), and those physical properties of materials are notoriously stubborn to changes. You know, some Richard Feynman once quipped "nature can't be fooled, dammit" - that extends to "water boils at 273.16K full stop (standard conditions), no, you're not going to change that".

Yes, you can often do more complex design. Sometimes though it costs you centuries to choose a good combination of existing physical properties (architecture), and sometimes it's "just" decades (Gravity Probe B). Wanna propose similar approach to software? :)

Re:What Should We Do to Prevent Software from Failing? by 8note on Monday May 20, 2019 @05:53PM (#19965663)
safety factor less than 1? you're planning that the thing will break early?
Re:What Should We Do to Prevent Software from Failing? by avmich on Monday May 20, 2019 @08:19PM (#19966600)
Liquid fuel rocket engines sometimes could be planned to work under the plastic deformation stresses, not elastic stresses. Given that their life-cycle is measured in seconds, such an approach - which brings some admirable weight savings - could produce results.