>By failing so quickly and often, we build mental models of code that correspond closely to reality. Okay, but those mental models are not close to reality sin

>By failing so quickly and often, we build mental models of code that correspond closely to reality. Okay, but those mental models are not close to reality since in 'reality' all those models consistently break in production use. We write code to work on platforms which run on top of other platforms, etc and each of those platforms breaks in weird inconsistent ways. The cargo-cult mantras like 'ship often' , 'move fast, break things' that people love to blog about are all useless here. (Note that I don't care much for the business aspect. For me, shipping reliable software is infinitely more valuable than making money shipping junk) I propose we don't ship _at all_ unless the software can be 'certified' to run for atleast a year. >We have debuggers that can stop time and examine every aspect of a running process. Its okay if you find that impressive. As someone who ships multithreaded embedded/systems code which has to run for months/years without crashing I find most tools to be rubbish for helping me catch the really hard to find bugs. It does not matter (from my customers POV) that the bug was in the OS or hardware or whatever. Maybe that is an 'impossible' standard to hold someone to, but that is exactly what I'm proposing.