logo
CHEATSHEETSTOOLSABOUT中文

Worse Is Better: The New Jersey vs. MIT Philosophies

In 1989, computer scientist Richard P. Gabriel wrote a legendary essay titled Lisp: Good News, Bad News, How to Win Big. In it, he dissected one of the most paradoxical realities of software engineering:

Why do technically inferior, crude systems (like C and UNIX) consistently conquer the world, while technically superior, architecturally pure systems (like Lisp Machines and Multics) fade into obscurity?

He named the two competing design philosophies: The MIT Approach ("The Right Thing") versus The New Jersey Approach ("Worse is Better").

The Two Competing Doctrines

                        The MIT Style ("The Right Thing")    The New Jersey Style ("Worse is Better")
                      ┌────────────────────────────────────┬──────────────────────────────────────────┐
Simplicity            │ Simple interface is paramount;     │ Simple implementation is paramount;      │
                      │ implementation can be complex.     │ interface can have minor warts.          │
                      ├────────────────────────────────────┼──────────────────────────────────────────┤
Correctness           │ Absolute requirement in all cases. │ Slightly better to be simple than        │
                      │ No compromises.                    │ 100% correct in exotic edge cases.       │
                      ├────────────────────────────────────┼──────────────────────────────────────────┤
Consistency           │ Absolute requirement.              │ Consistency can be sacrificed            │
                      │ No rough edges allowed.            │ if it keeps the implementation simple.   │
                      ├────────────────────────────────────┼──────────────────────────────────────────┤
Completeness          │ Must handle all known scenarios.   │ Completeness can be sacrificed whenever  │
                      │ No punting to the user.            │ implementation becomes too difficult.    │
                      └────────────────────────────────────┴──────────────────────────────────────────┘

The Classic Case Study: The Interrupted System Call

Gabriel illustrated the clash using a real problem in operating system design: what happens when a hardware interrupt arrives while a process is blocked in a long system call?

The MIT / Lisp Machine Way ("The Right Thing")

The MIT engineers believed the user program should never have to worry about low-level kernel scheduling interruptions.

  • The operating system kernel must carefully back out of whatever complex I/O state it was in.
  • It must roll back buffer pointers, undo mutations, reset the processor’s program counter to the instruction before the system call was invoked, and handle the interrupt.
  • Once the interrupt completes, the system call transparently restarts from scratch.
  • The Result: The user-space program sees an elegant, clean world where system calls are atomic and never fail randomly. However, the kernel implementation becomes monstrously complex, hard to debug, and fragile across different hardware architectures.

The New Jersey / UNIX Way ("Worse is Better")

Ken Thompson and Dennis Ritchie at Bell Labs (New Jersey) took one look at the rollback logic and said:

"Backing out multi-page buffer states and resetting instructions is way too complicated for our PDP-11 kernel. Let's just abort the call, return -1, set errno = EINTR (Interrupted System Call), and tell the programmer: 'Hey, an interrupt happened. Call the function again yourself.'"

// The New Jersey Compromise: User-space forced to handle kernel laziness
ssize_t n;
do {
    n = read(fd, buf, count);
} while (n < 0 && errno == EINTR);

To the MIT computer scientists, this was an abomination. The kernel was openly leaking its internal limitations into user code and forcing every programmer on the planet to write boilerplate retry loops.

And yet, UNIX won.

Why "Worse Is Better" Conquers the Market

Why did the New Jersey philosophy achieve total global dominance while "The Right Thing" lost? Gabriel identified four viral survival characteristics:

1. The Cost of Entry is Low

Because the implementation is radically simple, it can be written quickly by a small team. It can run on cheap, underpowered hardware (like the PDP-11 or modern embedded microcontrollers). In contrast, "The Right Thing" required expensive, specialized Lisp machines with custom microcode.

2. Effortless Portability

A simple implementation has fewer moving parts. UNIX and C could be ported to a new CPU architecture in a few weeks by a couple of engineers. A system designed under the MIT philosophy was so tightly coupled to theoretical hardware features that porting it was a monumental undertaking.

3. The 90% Solution Ships First

"Worse is Better" systems arrive in users' hands years ahead of "The Right Thing." By the time the theoretically perfect system is ready, the "worse" system has already captured the developer ecosystem, established standard libraries, and battle-tested its runtime in production.

4. Flaws Can Be Patched in User-Space

Once a simple system spreads, the burden of working around its flaws is distributed among millions of developers. Programmers simply write helper wrappers (like read_retry()) or language runtimes that hide EINTR. The ecosystem absorbs the defect, but retains the speed, simplicity, and ubiquity of the underlying platform.

Modern Examples in Tech

The "Worse is Better" dynamic didn't stop in 1989. It continues to dictate modern architectural winners:

  • JavaScript vs. Scheme / Smalltalk: JavaScript was hacked together in 10 days by Brendan Eich at Netscape. It had strange type coercion, scoping oddities, and rough edges. Yet its implementation simplicity and browser ubiquity made it the most widely deployed runtime in human history.
  • REST vs. SOAP / CORBA: SOAP had rigorous WSDL schemas, ACID transactions (WS-AtomicTransaction), and enterprise security specs ("The Right Thing"). REST was just crude HTTP URLs with unstructured JSON blobs ("Worse is Better"). REST obliterated SOAP.
  • Docker vs. Solaris Zones: Solaris Zones (2004) offered mathematically rigorous isolation, integrated file systems (ZFS), and rock-solid kernel guarantees. Docker (2013) was a thin, leaky wrapper around Linux cgroups and namespaces that frequently broke. But Docker was trivially easy to run on a laptop and compose via text files.

Architectural Takeaway

As engineers, our natural instinct is to strive for The Right Thing: complete architectures, seamless abstractions, and zero rough edges.

However, keep the New Jersey lesson in mind: Implementation simplicity is the ultimate survival trait. A solution that is 80% complete, dead simple to build, and easy to run on cheap infrastructure will almost always out-survive and out-compete a 100% complete architectural masterpiece.

Loading...