A few weeks ago, I learned about something called crash-only software (ht, Robert Greco). This is software that has no normal “start” or “stop” mechanisms. It can only be stopped by crashing it. Often this means unplugging the computer physically. It can only be restarted through some sort of failure-recovery routine, with a hard reboot being the most extreme kind. There’s a whole theory of crash-only software design apparently.
The idea of crash-only design steelmans a strawman idea of mine that has cropped up in multiple recent posts. In How To Fall Off the Wagon, I argued that falling-off-the-wagon is the right focal point for understanding self-improvement efforts. On the Unraveling of Scripts was about why major life transitions are necessarily messy. In The Adjacency Fallacy, I argued that career transitions necessarily involve a period of anomie caused by status and value disorientation. Crash-only is the more powerful version of all those ideas. From a crash-only perspective, falling off the wagon (and getting back on) isn’t the main thing. It’s the only thing.
A self-improvement system, or a management model for a business, that doesn’t solve for crash-only constraints isn’t a solution, because it will cost more in crash-recovery effort than the value it creates. Transition management of any sort has to be entirely about crash-only mechanisms.
Software ideas of crash-only design don’t port well to human lives and businesses. So how do you port the thinking?