Inverted problem solving, done naively, is an infinite task — you could kill all the pilots in infinitely and progressively improbable ways (e.g., use time-travel to kill someone in their chain of ancestry, or their pilot instructors, or the aircraft engineers, etc).
So inverted problem solving must identity the most probable modes of failure until their hypothetical resolution causes failure to becomes improbable.
This sounds a lot like unit tests, which in my experience are notoriously bad at correctly estimating probable modes of failure for complex units of functionality,
Contrast this to generative testing of simple units of functionality, which in my experience do in fact provide comprehensive coverage of failure modes.
Or contrast both of them to languages like Rust and Haskel which many claim to solve a set of discrete failure modes automatically by virtue of the limitations set upon problem solving itself.
It seems to me that it is better to set limits upon problem-solving that are known to often lead to failure rather than attempt to estimate the probabilities of an unknown infinite — i.e., identify types of failure modes across domains that have high failure rates and construct a framework of problem-solving that precludes those types.
This is done all the time in the form what I would call “worst-practices”. Cheating on your partner is almost always a bad way to increase marital happiness, and the framework of marriage excludes it (even “open marriages” require honesty as part of its framework).
Paul Graham puts cofounder disagreements at the top of his list of ways that startups fail — the most basic form of such failure being that cofounders disagree on whether to give up on their startup. Although there are infinite ways for cofounders to disagree, perhaps it is possible to proactively address the manner in which disagreements are identified and resolved before they become lethal. The only good solution I’ve seen to this problem is the advice to split equity equally — ensuring that the problem is more obvious and severe by amplifying its consequences.
This is similar to Rust — the consequence of a “poorly” written program is that it won’t run at all.
This is also why monopolies in America are sometimes broken up: a monopoly can succeed by failing, whereas a startup can only succeed by actually making something people want.
Perhaps a better framework for problem solving would be something like, Make Problems Catastrophic, or Burn Your Lifeboats, or Amplify Consequences of Failure.
It has always fascinated me that Leprosy doesn’t directly cause your body to fall apart — it indirectly causes failure by removing the feedback of pain. Without pain, we hurt ourselves unknowingly and profoundly.
Make Problems Painful?