Everyone has to evaluate the risk of the errors and act accordingly.
I forget my source, but IIRC the computer system actually noticed the pressure drop from the fuel lines (what with the exploding) and started the shutdown process, spinning down the turbos before the system was forcefully disassembled. Takes a while to turn off the turbos; a few hundred milliseconds really isn't enough time...
[0] Obligatory link to the Feynman report
http://www.nasa.gov/mission_pages/shuttle/flyout/flyfeature_...
[1] A cool article on the software running the shuttle
This is specifically why I couched my answer in terms of risk. This was not specifically about the computer system, this was about the mis-assessment of risk.
That said, you do not need to prove everything about your algorithm. I imagine that in the future, we'll write software with base runtime system that has some basic sanity properties (proved) and on top of that, there will be layer that handles things in a more flexible way. Kind of like having Challenger JVM which is provably correct and never crashes and lots of apps on top of that :-)
Video games already do something like this to hide latency in multi-player scenarios. A generalized solution would be interesting, although given our track record with shared state concurrency, it may prove too confusing for the average dev.
