[Classic Reread][1/n] Worse Is Better

Recently I wanted to work through a serious round of classic computer science and software architecture reading. The list came from GPT Pro:

Find dozens of essays and papers similar to The Bitter Lesson, No Silver Bullet, and You and Your Research.

Codex has made writing much cheaper, so I wanted to use AI writing as a form of retrieval practice.

I picked Worse Is Better first because it is short, and also because I had heard the name since my student days without ever actually reading it.

It asks a very direct question: why do so many systems that are not as “correct” end up winning adoption first, and eventually even become the standard?

Worse Is Better

In The Rise of Worse is Better, Gabriel contrasts two design philosophies:

• The Right Thing: prioritize a simple interface, correct behavior, strong consistency, and complete coverage. More implementation complexity is acceptable in order to preserve correctness, consistency, and completeness.
• Worse Is Better: prioritize implementation simplicity first. Correctness, consistency, and completeness all matter, but if they make the implementation too complex, they can be traded down for a while.

The real disagreement is not whether things should be done well. It is what you protect first when simplicity, correctness, consistency, and completeness cannot all be satisfied at once.

• The Right Thing: the system should absorb more complexity on behalf of the user. The interface and semantics should stay as clean as possible. A more complex implementation is acceptable because the complexity is encapsulated inside the system.
• Worse Is Better: the system itself must become simple first, so it is easier to implement, port, and spread. It is acceptable for users to absorb a bit more complexity because the more important thing is that the system survives.

There is a classic example in the essay. When a system call gets interrupted, the The Right Thing instinct says the system should restore enough state for the program to continue gracefully. Unix takes a more direct path: the call can fail, return an error code, and let the program retry on its own.

The Right Thing sees that as pushing complexity onto user programs. Worse Is Better sees implementation simplicity as the higher priority, and a retry loop as an acceptable cost.

Behind that example is the split fate of systems like Lisp, Unix, and C. Elegant systems do not automatically become the winners. Gabriel’s judgment is that Worse Is Better often has the easier path to early dominance:

• easier to implement
• easier to port
• lower machine-resource requirements
• easier to win adoption first

Once a system wins adoption, it grows an ecosystem, patches, tutorials, toolchains, and historical inertia. At that point even a more elegant alternative becomes awkward: yes, I support it in principle, but no, I am not switching the project today.

Gabriel also describes two ways The Right Thing tends to evolve: big complex system and diamond-like jewel. The former looks like Common Lisp: nearly complete in functionality, but large, slow to implement, tooling-heavy, and demanding on hardware. The latter looks like Scheme: small and beautiful, but that very beauty makes both design evolution and efficient implementation hard. One becomes too large, the other too pure, and both can still lose on adoption.

So the real value of the essay is not that it praises “worse.” It is that it separates two different questions: being more right in engineering terms, and being more likely to win adoption inside an ecosystem, are not the same thing.

One side note matters too. This was not a talk that landed to universal applause. Gabriel later recalled that after the keynote there was a stretch of silence, and then people like Gerry Sussman openly pushed back on it. That detail is useful. It shows the essay was not a line that later got polished into wisdom. It was an uncomfortable judgment even at the time.

Thirty Years Later

I think the logic still holds, but only if the boundary is stated clearly.

Worse Is Better mostly explains the adoption boundary: how a system wins adoption first and enters the real world. Once it reaches the leverage boundary, meaning the system is heavily used and starts carrying more complexity, The Right Thing becomes important again.

Over the last thirty years, the same pattern has shown up again and again:

Example	The Worse Is Better side	The later repair layers
JavaScript	Brendan Eich built the first prototype in ten days. The language was not elegant, but it shipped in every browser by default.	TypeScript, lint, bundlers, frameworks
Python	Performance and the type system were never its strong sides, but it was easy to write, easy to read, and quick to get feedback from.	type hints, formatters, lint, packaging cleanup
Git	The command line is unfriendly, but the data model is strong, distributed collaboration works well, and the ecosystem formed quickly.	GUI tools, GitHub workflow, various porcelain tools
REST/JSON	Less complete and less formally rigorous than systems like CORBA, but much easier to understand, debug, and integrate.	OpenAPI, schemas, validation, typed clients
Claude Code, Codex	Unstable and imperfect, but already useful enough to enter real workflows.	evals, sandboxes, verification, harnesses

These examples should not be applied mechanically. But they all point to the same thing: being more complete and more polished does not necessarily make a system more likely to win adoption first. The common pattern is Worse Is Better core + The Right Thing repair layers.

This is not “rough always beats rigorous.” It is closer to: get on the train first, then pay for the ticket later. Enter reality first, and then slowly add order for reality.

Engineering correctness and ecosystem adoption are not the same problem. The hard part is knowing when to use Worse Is Better, and when to switch back to The Right Thing.