Better is Worse
There's a popular(ish) concept among the Twitterati/developer community known as "Worse is Better"—"the idea that quality does not necessarily increase with functionality—that there is a point where less functionality ('worse') is a preferable option ('better') in terms of practicality and usability."
In it's purely technical/developer form, it's a proto-version of Lean/Agile and Facebook's "move fast and break things" model. i.e. Optimize for quick iteration cycles, optimizing for customer-facing UX, rather than for top-down "functionality"/minimizing technical debt. (See Gwern's Bitcoin is Worse is Better.)
Better is Worse
Surprisingly, very little has been written about the reverse of Worse is Better (WiB), Better is Worse (BiW!). With Better is Worse, the initial "goodness" of the thing eventually leads to a "negative" outcome. Let's look at a specific example:
The Innovator's Dilemma: A company is "better" by making money from its current customers, continuing to serve them, and moving up the cost curve. But because the company is "winning", it doesn't "see" some of the niche/lower cost products that startups are building. By the time the big company realizes this, it's too late and it's been "disrupted" by the startup. In other words, Better is (in the end) Worse.
BiW and WiB as Multi-Perspective Thinking
I find myself increasingly using BiW and WiB outside the technical context. In fact, I think it's a great way to push for multi-perspective thinking. i.e. For anything with a "good" outcome, search for the "bad" outcome as well (and vice versa). Some other examples:
- Erik Torenberg applies Better is Worse to jocks, here:
- I use Better is Worse to understand my "superpower/shadow" dynamics. i.e. My "superpowers" (things I'm good at) can lead to negative outcomes. This can happen in a similar way as Erik described above—where an initially positive attribute made me "ignore/not cultivate" a part of myself. (e.g. I'm super cerebral, which had [traditionally] kept me from understanding my spiritual, emotional, and physical sides.) But it can also manifest through leveraging the "superpower" for negative outcomes. (e.g. In childhood, I used to use my ability to understand others to "be a class clown/play games/manipulate" my peers.) In other words, Better is Worse because you don't cultivate a holistic self (because you could get by without it) and because you can use your abilities for bad ends.
- The creative framework that Mark Rosewater loves, "Constraints Breed Creativity", is an example of Worse is Better. Initially, you may think the constraint it bad—it puts you in a box! But in fact the constraint allows you to be more creative.
- People often use Worse is Better for filtering to "get the right people". Early Adopters are generally an example of this. You don't want rando's using your initial product, so you release a crappy version of it (Worse) that leads to only the "true believer" Early Adopters to use it and give you feedback (Better). You can also use this for events: make an event at a super early time and don't serve food. It's "Worse", but only the super passionate people will come (Better). We did this for the 1st year of ETHDenver as well—make the hacker application super long so only passionate hackers apply (not random ICO folks). Related: I heard that MakerDAO made their documentation purposely confusing at first so that only sharp true believers could make it through (and be part of their early community).
In some ways, you can think of BiW and WiB as abstract ways to talk about a balancing feedback loop. This is in contrast to a reinforcing feedback loop, like Liquidity Begets Liquidity, where Better is Better or Worse is Worse.
In the end, my key points are:
- We should use Better is Worse in addition to Worse is Better
- We should more often apply them to domains outside of programming—they are useful for multi-perspective/systems thinking generally.
Vote on future articles here!