[WalterBright]

> probabilistic

I don't remember the numbers, but one had to show that the likelihood of failure was less than 1 flight in XXXX where XXXX was a very large number.

> I wish more software was built to the standards of aerospace control system best practices...

I am much more ambitious. The Deepwater Horizon disaster, the Fukushima nuke plant failure, the Toyota acceleration failure, etc., are all designed with an utter disregard for lessons that aviation learned long ago. To wit:

1. a failure of one subsystem shall not propagate to another (zipper effect)

2. a failure of one subsystem shall not compromise the whole

3. once any such failure is detected, that subsystem shall be assumed to be compromised by demons, and must not be allowed to continue

4. you cannot educate people into not making mistakes

5. if you punish people who make mistakes, they will conceal mistakes instead of being forthcoming about fixing them

Those principles have strongly influenced all my engineering work since, and I've tried to propagate them among my colleagues (with mixed results).

[WalterBright]

For example, the good old `assert` in software. Asserts are to detect impossible states, and hence if an assert trips, the software is in an unknown state, and what it will do next is unpredictable. Therefore, an assert must go directly to jail, not pass Go, and not collect $200.

I get pushback all the time on this,

1. people use assert()'s to validate input

2. people insist that their program can continue operating after an assert trips

3. people insist that their program cannot be allowed to fail, and that they are capable of predicting what their program will do next