Suppose I Wanted to Kill a Lot of Pilots (2020)

> "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.

> 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."

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.

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.

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.

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.

Yep, that's how Stalin's science worked if you dared to think that you know better how the system should be run. For example, the USSR space program leader Korolev lost his teeth from malnutrition in a Gulag camp between his earlier rocketry work and sending Gagarin to space; and arguably the best Russian agronomist/geneticist Vavilov died in prison because he dared to criticize the pseudoscience of Lysenko, who was favored by Stalin at the time.

Except all the outrage came from people who never lived in his buildings, and the ones who did gave it overwhelmingly great reviews.

Suppose I never want to know what my software is doing...