A process that can not survive a single programmer having a bad day is not a high reliability process. That problem is trivially easy to "solve" in any number o

A process that can not survive a single programmer having a bad day is not a high reliability process. That problem is trivially easy to "solve" in any number of ways. 1. You can have multiple people whose job is to fully understand that code and review it. 2. You can have independent 3rd party reviewers whose job is fully understand the code and review it. 3. You can have adversarial reviewers from your competitors review the code with veto power over your code if they discover and can prove there is a defect. 4. You can have a requirements doc that traces to the code and a corresponding test to exercise that property. 5. You can verify that everybody understands the source by reading the compiled output to verify that it correctly traces to the expected source constructs. 6. You can have multiple people develop independent systems with the same functionality to run in parallel to crosscheck results with each other. 7. You can have those systems developed in isolation from each other so that they share no code or ideas giving even greater independence. 8. You can run these systems on the same and different hardware in parallel to provide even more independence and crosschecking. Every single one of these raises the bar from a single programmer having a bad day to requiring multiple people independently failing on the same code which is multiplicatively less likely. Every single one of these is something that is actually done for high criticality avionics software. Any "high-reliability" process that seriously considers a single programmer having a bad day as a material unsolved risk is made by complete amateurs. This does not mean high criticality avionics software is perfect, it just means that the concerns are more about actually hard problems such as how to prevent errors where a dozen brilliant programmers cross-checking each other will be unable to prevent the problem without the process. To put the difference in reliability between these systems into perspective, a "high-reliability" commercial system like AWS only promises 99.99% uptime in their standard SLA. In contrast, the 737 MAX, which most people consider an absolute deathtrap and evidence of the terrible quality of avionics code, had one failure per ~200,000 flights or 99.999% per-flight reliability (10x the reliability if we compare number-of-flights to seconds-of-uptime). If we were to consider all high-criticality avionics software, avionics software has not been implicated in any crash for the last 10 years except for the 737-MAX, so at ~10,000,000 flights per year for a total of ~100,000,000 that means avionics software has 99.999998% per-flight reliability or 5,000x the reliability if we compare number-of-flights to seconds-of-uptime.