This is a very powerful way of thinking, and one I use often when thinking about things like career direction and personal life. I think I also learned it from Charlie Mungers book, but I don't recall clearly. However, it does have two downsides as a way of engineering thinking that is worth being aware of: completely enumerating badness is hard, and the solution space might be much sparser than the problem space.<p>Say I'm designing a distributed replication protocol, basically trying to discover Paxos from first principles. So I start with things that don't work, like "fire the packets off at each server and hope they arrive in the order I sent them". So I close that gap. Then find the next problem, and close that, and so on. That finds a lot of problems, but doesn't necessarily find the solution: the space of problems is dense, but the set of solutions is small and tightly clustered in a few "islands". So I can churn through loads of broken protocols without identifying the key insight that leads to a working protocol. In the case of Paxos, that's having acceptors return their previously accepted values and having proposers drive those values instead of their own proposals. It's a brilliant insight, which doesn't seem to lead directly from the set of problems.<p>Then there's the issue with enumerating badness. What are all the ways a server can suffer gray failure? Spend a minute writing them down (bad RAM, bad RAM that still passes ECC, CPU corrupting floating point calculations, etc etc). Ask a colleague to do the same. Compare your answers, and you'll likely find their list of badness is different from yours. This is where you need, again, a simplifying insight (like "look from the outside" or "use a quorum" or whatever). In other words, sometimes it's easier to enumerate goodness than badness.<p>I don't mean to attack a strawman version of this way of thinking. It's a useful tool. But it's one analysis tool, and it's worth being careful of applying it to the exclusion of other ways of analysis that lead more directly to the synthesis of the "correct" answer.
I’ve seen this used this as a teaching technique in outdoor education to good effect. For example when teaching boat safety, delivering a short class on “how to be great at drowning.” Or when in the backcountry: “How to make sure you get hypothermia today.”<p>Students usually think it’s funny, and it’s often not hard for them to invert the steps to avoid the outcome. For example, if step one of being great at drowning is “get drunk,” then students understand you’re telling them not to drink while boating.<p>It helps students acknowledge the reality that outdoor sports can be dangerous, but without getting too serious, and giving them clear steps to reduce the risk.
<i>TRIZ practitioners quickly realized that the root cause of some problems cannot easily be identified, which makes a frontal assault on them impossible. This kind of problem is solved with TRIZ’s Anticipatory Failure Determination mental model — rather than solving for success, solve for failure.</i><p>This is pretty darn close to <a href="https://en.wikipedia.org/wiki/Apophatic_theology" rel="nofollow">https://en.wikipedia.org/wiki/Apophatic_theology</a> : I can't tell you what The Good Thing is, but I can tell you many things that it is _not_.
Tangent: Rather than killing pilots, work on preventing them from becoming pilots in the first place. Perhaps join neighborhood efforts to close all the small airports where people learn to fly.<p>Now apply the "reverse thinking" described in the article. To enable the development of more pilots, work on increasing the number of small airfields.<p>Apply this to your own world. What do you need to do to increase the pipeline of talent available to your company?<p>The origin story for the RaspberryPI is a prime example:<p><a href="https://www.zdnet.com/article/we-thought-wed-sell-1000-the-inside-story-of-the-raspberry-pi/" rel="nofollow">https://www.zdnet.com/article/we-thought-wed-sell-1000-the-i...</a>
A lot of "security mindset" comes from this principle as well. In theory, you should have strong barriers everywhere, but we're not to that level of maturity yet. (I still hope to see some successful implementation of "capabilities" like in E or something before my career is over. That's an example of what I'm thinking of as maturity.) In practice you get a long way just by writing some code down, and then thinking <i>How would I break this?</i> Oh, hey, if I put this combination of characters into my decoding routine I'll get up to the SQL command level, oh, if I just assume that a user with no email is an admin and I let users change their email, they can become admin, etc.<p>It isn't theoretically ideal, but it's a lot better than <i>not</i> thinking this way.
It took a second for me to make this connection, but the Charlie Munger in this article is the same Charlie Munger who designed that windowless dorm at UCSB that made the news a few days back. [0] I wonder if he applied the same principles to designing that building.<p>[0] <a href="https://www.independent.com/2021/10/28/architect-resigns-in-protest-over-ucsb-mega-dorm/" rel="nofollow">https://www.independent.com/2021/10/28/architect-resigns-in-...</a>
This is a dupe of the same article (posted by the same user) on different hosts over the past 4-5 months.<p><a href="https://hn.algolia.com/?q=+%09+%09Suppose+I+Wanted+to+Kill+a+Lot+of+Pilots" rel="nofollow">https://hn.algolia.com/?q=+%09+%09Suppose+I+Wanted+to+Kill+a...</a>
I've been on a few projects where there has been no obvious way forward. So to find the least worst option, I've started off by desiging a really bad design (along with polished diagrams and RAIDS etc..)<p>This generally invokes good/ heated discussion on how not to do things - which always seems to get poeple talking - as opposed to asking people what they think is the best way forward. People are better at telling you how thngs can't work than saying how to make things work<p>Keep track of all the choices and design decisions and do this iteratively and you have you least worse option.<p>I think I've accidently followed the TRIZ method
Pre-mortem exercises (opposite to the typical post-mortem, after something has gone wrong) can be a really fun process of discovery and ideation.<p>Unfortunately though, I have yet to run one that actually helped us avoid the exact risks we discovered!
I've long carried a suspicion that some relentlessly negative people are expressing their gift for TRIZ and troubleshooting.<p>Because their early years are filled with people who are push back against this ability, their nature tends to devolve into unproductive reactions.
Good advice. Looking at things from the opposite perspective helps a lot.<p>It’s easier to see where things go wrong than where they go right. You can just list wrong thing after wrong thing and a solution appears once you’ve scoped out the things that don’t work.
> Charlie inverted the problem in a similar way to the TRIZ practitioners — if he wanted to kill pilots, he could get them into icy conditions whereby they couldn’t continue flying, or put them in situations where they would run out of fuel and fall into the ocean. So he drew more applicable maps and better predicted the weather factors that were relevant by keeping in mind the best ways to do the exact opposite of bringing his pilots home.<p>I actually like this train of thought. Though, to be fair, this is the basis for chaos engineering. How can we destroy production? By actually actively destroying production ALL THE TIME! This way, we design our production systems to be as reliable as possible
This reminds me a bit of FMEA (Failure Mode and Effects Analysis) [1] which is used heavily by the medical, automotive, and aerospace industries. Basically you try to think of all the ways that a device or process will fail, what the hazards are from those failures, and how easy it is to detect them. Then based on the risks you've uncovered, you try to mitigate the worst ones (high likelihood, low detectability, worst outcomes - e.g. death).<p>[1] <a href="https://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis" rel="nofollow">https://en.wikipedia.org/wiki/Failure_mode_and_effects_analy...</a>
This brought immediately to mind the Residuality Theory as created by Barry O'Reilly - here a dry but useful introductory piece: <a href="https://www.sciencedirect.com/science/article/pii/S1877050921007420" rel="nofollow">https://www.sciencedirect.com/science/article/pii/S187705092...</a> and another one linking it to software development: <a href="https://www.cutter.com/article/residuality-theory-introduction" rel="nofollow">https://www.cutter.com/article/residuality-theory-introducti...</a>
For successful network design anticipating as many failure modes as possible isn't just a clever mental hack, it's absolutely essential. I suspect this is true for many engineering disciplines.<p>What I hadn't considered is applying this technique to more general (non-technical) life problems/optimizations.
> "He eventually pulled together lists of best practices and key principles of innovation based on this work, which became “the theory of inventive problem solving” alternatively known as TRIZ.<p>> Believing he was on to something, he got a little excited and sent Joseph Stalin a letter in 1948 criticizing the lack of innovation within the Soviet system. This earned him a political prisoner title and a 25-year sentence in the Gulag Archipelago."
Great article, reminds me of an older hn post about thinking by inversion. <a href="https://news.ycombinator.com/item?id=23905221" rel="nofollow">https://news.ycombinator.com/item?id=23905221</a>
> For example, let’s say you are trying to figure out “How can I have a great, fulfilling career?” Instead, ask yourself “How can I have a terrible, worthless career?” and whittle away at the choices that you know will ensure that outcome[...]<p>This sort of sounds like the old joke of asking a sculptor how they carved a horse and the sculptor reply's: "Start with a block of stone and remove everything that doesn't look like a horse."
great article. This seems similar to the idea of eliminating wrong answers to try to guess the right answer if you don't know the right answer from given choices.