worse is still better
In 1989 Richard Gabriel wrote an essay trying to explain why the elegant thing keeps losing to the crappy thing. He called the crappy thing “worse is better.” He was a Lisp guy watching C eat the world, and he could not make the math work. The better-designed system lost. The worse-designed system won. Every time.
Thirty-five years later it’s still the only theory of software that predicts anything.
Gabriel set up two camps.
The MIT camp — call it the right thing — ranks its priorities like this: correctness first, then consistency, then completeness, and simplicity last, where simplicity means a clean interface even if the guts underneath are a nightmare. Get it right. Cover every case. Never surprise the user. Do the work so they don’t have to.
The New Jersey camp — worse is better — flips the stack. Simplicity comes first, and it means the implementation stays simple, even if that makes the interface uglier. Correctness is good but you can ship without it. Consistency is negotiable. Completeness barely registers.
Same four words — simplicity, correctness, consistency, completeness. Opposite order. The whole history of computing lives in that reordering.
His example was an interrupt. A user program calls into the operating system, and mid-call a keystroke arrives.
The right thing: the system unwinds cleanly, handles the interrupt, and restores your program exactly where it was. You never know it happened. This is correct. This is also brutally hard, and every routine in the kernel has to be written to survive being yanked mid-stride.
The New Jersey thing: the system call just fails. Returns an error code. Deal with it. Now the kernel is simple and the pain moves to every programmer who ever calls that function.
MIT says New Jersey is wrong. New Jersey says the right thing is too complicated to build, and a simple thing that ships beats a correct thing that doesn’t. Then Gabriel delivers the line that has aged like nothing else in our field:
Unix and C are the ultimate computer viruses.
Simple enough to run on hardware that couldn’t dream of running the right thing. Good enough at the 50–90% mark. So they spread — to the next machine, the next school, the next kid who learned them because they were there. By the time the elegant system was ready, there was nowhere left to plant it. The worse thing had already colonized the host.
Here’s what nobody wants to hear: this keeps happening, and the worse thing keeps being right to win.
JavaScript. Designed in ten days, shipped with the bugs in, mutated into the substrate of the entire internet. Every serious language watched from the sidelines while the ten-day language ate client, server, build tooling, and desktop.
JSON beat XML because it did less. REST beat SOAP because it did less. Docker beat the correct-but-baroque configuration-management dream because you could docker run a thing in an afternoon. MongoDB shipped without your data being safe and won a decade of startups anyway, because “it just works on my laptop” is a survival trait and “provably consistent” is not.
Twenty years running infrastructure and I’ve stopped betting against New Jersey. The cleanest architecture in the room loses to the one a tired engineer can stand up before lunch. Not because the tired engineer is dumb — because shipped and spreading beats correct and rare, and the market only counts the first thing.
Now the biggest New Jersey machine ever built.
A large language model is worse-is-better with the dial at eleven. It is not correct. It will confidently hand you a function that doesn’t exist. It is not consistent — same prompt, different answer. It is nowhere near complete. By every MIT metric it should never have shipped.
And it is spreading faster than any tool in the history of the field, because it clears the same bar Unix cleared: good enough, most of the time, on hardware you already have, usable by someone who was never going to read the manual. The right-thing crowd is still writing papers about hallucination and alignment while the worse thing installs itself into every editor, every terminal, every workflow on earth.
The virus doesn’t wait for correctness. It never did.
Gabriel wrote the essay ambivalent, and he stayed ambivalent. He gave the New Jersey argument its best case precisely because he was a Lisp partisan who could feel it winning and hated that it was right. His conclusion was a shrug with a knife in it:
The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.
Swap the nouns. In 2026 we have a good coding assistant. The bad news is it’s a stochastic parrot that can’t count the r’s in strawberry, and it’s already in production everywhere.
The lesson was never “build worse things.” It’s that the world doesn’t reward correctness. It rewards spread — and spread comes from being simple enough to survive contact with reality, cheap enough to try, and present enough to become the default before anyone finishes arguing about whether it’s any good.
If you’re the MIT type — and after twenty years I still am, on my worst days — the essay isn’t comfort. It’s a warning. The right thing only wins if it ships before the worse thing owns the host.
Usually it doesn’t.