Sometimes you run across an idea so counter-intuitive and brain-bending that you immediately want to splice it into every domain you can think of. Sort of like trying a novel chemical compound against a bunch of cancers: does it work here? How about here? Or here?
That’s how I feel about crash-only software (link goes to a PDF in Google’s viewer). Don’t pay too much attention to the technical details; just check out the high-level description:
Crash-only programs crash safely and recover quickly. There is only one way to stop such software—by crashing it—and only one way to bring it up—by initiating recovery.
Wow. The only way to stop it is by crashing it. The normal shutdown process is the crash.
Let’s go a little deeper. You can imagine that commands and events follow “code paths” through software. For instance, when you summoned up this text, your browser followed a particular code path. And people who use browsers do this a lot, right? So you can bet your browser’s “load and render text” code path is fast, stable and bug-free.
But what about a much rarer code path? One that goes: “load and render text, but uh-oh, it looks like the data for the font outlines got corrupted halfway through the rendering process”? That basically never happens; it’s possible that that code path has never been followed. So it’s more likely that there’s a bug lurking there. That part of the browser hasn’t been tested much. It’s soft and uncertain.
One strategy to avoid these soft spots is to follow your worst-case code paths as often as your best-case code paths (without waiting for, you know, the worst case)—or even to make both code paths the same. And crash-only software is sort of the most extreme extension of that idea.
Maybe there are biological systems that already follow this practice, at least loosely. I’m thinking of seeds that are activated by the heat of a forest fire. It’s like: “Oh no! Worst-case scenario! Fiery apocalypse! … Exactly what we were designed for.” And I’m thinking of bears hibernating—a sort of controlled system crash every winter.
What else could we apply crash-only thinking to? Imagine a crash-only government, where the transition between administrations is always a small revolution. In a system like that, you’d optimize for revolution—build buffers around it—and as a result, when a “real” revolution finally came, it’d be no big deal.
Or imagine a crash-only business that goes bankrupt every four years as part of its business plan. Every part of the enterprise is designed to scatter and re-form, so the business can withstand even an existential crisis. It’s a ferocious competitor because it fears nothing.
Those are both fanciful examples, I know, but I’m having fun just turning the idea around in my head. What does crash-only thinking connect to in your brain?