'Worse Is Better'

The Philosophy

"Worse is better" comes from Richard Gabriel's 1989 essay comparing the MIT/Stanford approach (get it right) to the New Jersey approach (keep it simple). The surprising conclusion: the "worse" approach often wins.

The "worse" approach produces software that's easier to implement, easier to understand, and easier to port. These advantages compound: simpler software gets used more, which means more feedback, more contributors, and faster improvement.

Linux vs. Minix: The Classic Example

In 1991, there were two Unix-like operating systems in development:

Tanenbaum famously told Linus that Linux was "obsolete" and that monolithic kernels were a "giant step back." He was technically correct. And yet Linux now runs most of the world's servers, smartphones, and embedded devices.

Why "Worse" Wins

1. Simpler Software Spreads Faster

Complex software is hard to understand, hard to port, and hard to modify. Simple software can be picked up by anyone, run anywhere, and adapted to new needs. Viral adoption requires simplicity.

2. Good Enough Is Good Enough

Users rarely need perfection. They need something that solves their immediate problem. A working 80% solution today beats a perfect solution next year.

3. Imperfection Invites Contribution

DHH made an interesting point: releasing slightly broken software invites collaboration. If your project is perfect, there's nothing for others to do. If it has rough edges, contributors can make meaningful improvements.

4. Real Users Beat Theoretical Users

"The Right Thing" optimizes for theoretical use cases. "Worse is better" optimizes for real users with real problems. The feedback from real usage is more valuable than any amount of upfront design.

Ruby: The Exception?

DHH noted something interesting: Ruby is unusual in that it felt polished from the start. Matz spent years refining Ruby before releasing it, and it showed. Most languages improve through iteration; Ruby arrived with clear vision.

Rails itself followed "worse is better." The early versions were rough, missing features that "enterprise" frameworks had. But they solved real problems for real developers, and the community filled in the gaps.

Applying "Worse Is Better"

1. Ship Before You're Ready

If you're not embarrassed by v1, you waited too long. Ship something useful but incomplete. Real user feedback is more valuable than your assumptions about what's needed.

2. Simplicity Over Features

Every feature adds complexity. Every option is cognitive overhead. The simpler product often wins not despite having fewer features, but because of it.

3. Leave Room for Contribution

Don't solve every problem yourself. Leave obvious gaps for the community to fill. Contributors who solve their own problems become invested advocates.

4. Optimize for Understanding

Can a newcomer understand your system in an afternoon? If not, it may be too complex to spread. Simpler architectures win because more people can work with them.

5. Polish What Matters

"Worse is better" doesn't mean everything should be sloppy. It means prioritize ruthlessly. Polish the core experience. Let secondary features be rough.

When "The Right Thing" Is Actually Right

"Worse is better" isn't universal. Some contexts demand correctness:

• Safety-critical systems: Medical devices, aircraft, nuclear plants. "Good enough" can kill people.
• Security: "Mostly secure" isn't secure. Cryptography, authentication, and financial systems need to be correct.
• Data integrity: Databases that "usually" don't lose data aren't acceptable. Some systems must be perfect.

Know when you're building something where "worse" is acceptable and when you're building something where correctness is mandatory. The wisdom is in knowing the difference.

The Courage to Ship Imperfect

"Worse is better" is ultimately about courage—the courage to ship something you know is imperfect. The courage to let users see rough edges. The courage to iterate in public rather than polish in private.

DHH shipped Rails when it was "worse" than J2EE by every enterprise measure. Linux shipped when it was "worse" than Minix by every academic measure. Both changed the world precisely because they shipped.