Architecture & design · Book notes
Worse is Better and deciding which simplicity to pay for
Richard Gabriel's Worse is Better gets quoted as permission to ship rough work, but it's really a choice between two kinds of simplicity, and you have to pick which one your product pays for.
All of us are in this push and pull between, oh, one day this thing might be used by a million users, and so therefore I should build the perfect abstraction, because perfectly modeling how I think that this thing could be used one day is the right way to do this.
The attraction towards worse-is-better has been around for a long time.. in 1990, Richard Gabriel (a Lisp person) wrote an essay trying to explain why Unix and C were winning and Lisp (“the right thing”) was losing. That essay was The Rise of Worse is Better, which splits the field into two camps: MIT and New Jersey.
The New Jersey camp (early Unix, C) made one specific trade: the essay says “implementation simplicity was more important than interface simplicity.” The MIT camp paid the opposite price, keeping the interface simple no matter what it cost to implement.
If you’re trying to gain customers and you want to make it simpler than your competition, you probably need to do the right thing from a simplicity standpoint. That’s where that extra effort comes in. If you need to just down and dirty get scrappy, the simplicity of implementation is probably more important.
These are two kinds of simplicity, and they charge it to different parties. Simple implementation means it’s cheap for the builder, easy to ship and extend. Simple interface means it’s cheap for the user, costly for the implementer. Which does this project pay for? I think you should say that out loud before you write any code. Saying one thing or the other leads to very different products.
Just because it’s worse doesn’t make it better. Just because you don’t think about some of these details doesn’t mean that you shouldn’t think about it. You can actually make worse code that no one will ever use or want or is so poorly designed it can’t be maintained. So this is not an excuse to just have poor craftsmanship.
That said, if you’re going to build a scrappy version, it still has to be good enough that people will want to use it and that someone else can maintain it after you. So “Worse” in this case is more about the scope of what you build. You still have to care about what you’re doing.
You can optimize for a set of trade-offs and you say, look, if we can move fast and keep it simpler, that’s better than being complete and consistent and correct. And really what worse is better is all about is valuing outcomes over process.
Gabriel never resolved the question himself, which I find oddly reassuring. He spent a decade arguing with his own essay, including writing a rebuttal under the pseudonym Nickieben Bourbaki. In his own history of the idea, he writes “I still can’t decide” and the page ends “Decide for yourselves.” Which is of course the real answer. The call is yours to make for your product, and to make again for the next one.