Why Worse Always Wins

Every single day, you run code that was designed to fail.

It is running on your machine right now. Not because of a developer's mistake, and not because of a bug. But because more than fifty years ago, a group of engineers at Bell Labs decided that forcing you to write boilerplate error-handling loops was better than writing a theoretically "correct" operating system. They intentionally offloaded the complexity from the kernel onto the programmer, choosing a messy, compromised implementation over elegant architectural purity.

This decision didn't just shape Unix; it established a brutal selection pressure that still governs the tech industry today. It explains why ugly, viral implementations consistently outsurvive beautiful, correct designs, and why we, as developers, cannot stop walking the dirt paths of software design.

And they were entirely right.

The Ghost in wrapper.c

Open up the Git codebase. Navigate to wrapper.c and find the xread function.

Inside, you will find a loop that looks something like this:

ssize_t xread(int fd, void *buf, size_t len)
{
    ssize_t nr;
    while (1) {
        nr = read(fd, buf, len);
        if (nr < 0 && errno == EINTR)
            continue;
        return nr;
    }
}

This code is running on your machine right now. Every time you pull, commit, or check out a branch, this loop is spin-retrying because of a design decision made at Bell Labs in the early 1970s.

When Unix was being designed in Murray Hill, New Jersey, the engineers ran into a problem: what should happen if a system call, like reading from a slow device, is interrupted by a hardware signal?

If you were designing a theoretically "correct" operating system, the kernel would handle the interruption transparently. It would save the state, process the signal, and resume the read call exactly where it left off. The user-space program would never know it happened.

Unix did not do that.

Instead, the Unix kernel throws up its hands, aborts the read, and returns -1 with errno set to EINTR (Interrupted System Call). It essentially tells the programmer: "Something happened. Not my problem. You deal with it."

This design decision is more than 50 years old. It forces every systems developer to write boilerplate wrapper loops around basic I/O operations. It is messy. It is inconvenient.

And it conquered the world.

The Essay That Explained It All

In 1989, Lisp pioneer Richard Gabriel wrote a paper titled "Lisp: Good News, Bad News, and How to Win Big." Embedded inside was a short section that has since become legendary: "The Rise of Worse Is Better."

Gabriel contrasted two fundamental philosophies of software design:

The MIT Style ("The Right Thing")

• Interface Simplicity: The user-facing interface must be simple and clean, even if the implementation becomes incredibly complex.
• Correctness: Incorrectness is simply not allowed.
• Consistency: The system must be totally consistent. If a feature causes inconsistency, it must be omitted.
• Completeness: The design must cover all reasonably anticipated scenarios.

The New Jersey Style ("Worse Is Better")

• Implementation Simplicity: The implementation must be simple, even if it means the interface is slightly uglier or forces complexity onto the developer.
• Correctness: Correctness is highly valued, but implementation simplicity is more important than absolute correctness.
• Consistency: Consistency is important, but it is better to sacrifice consistency for simplicity of implementation.
• Completeness: The system does not need to cover everything. It is better to ship a 70% solution that is easy to implement and port.

To a computer science theorist, the MIT style is the obvious choice. We want clean interfaces, correct code, and elegant systems.

But Gabriel noticed a dark pattern: the New Jersey style has far better survival characteristics.

C++: The Great Virality

Consider the birth of C++.

In 1979, Bjarne Stroustrup was working at Bell Labs. He wanted to bring the modularity and object-oriented capabilities of Simula to the speed and efficiency of systems programming.

Stroustrup faced a classic choice:

1. Build the Right Thing: Create a brand new, highly elegant, object-oriented systems language from scratch.
2. Build the Simple Thing: Bolt object-oriented features directly onto C, inheriting all of C's quirks, syntax issues, and memory unsafety.

He chose the second option, initially naming it "C with Classes."

C++ was not elegant. It was a preprocessor that compiled down to standard C. But because it was fully compatible with C, it could run on every machine that already had a C compiler.

Developers did not have to rewrite their existing libraries, learn an entirely new toolchain, or abandon their legacy systems. They just compiled their C code with the new compiler and gradually adopted classes.

By the time cleaner, more elegant languages came along, C++ had already established a massive ecosystem. It became the foundation of modern operating systems, browsers, game engines, and databases.

The ugly, compatible solution ran circles around the elegant, clean-slate alternatives.

The Adoption Gradient

If we formalize Gabriel's observations, we find a rule governing technology adoption:

The long-term survival of a technology is inversely proportional to the friction a newcomer faces when trying to get it running for the first time.

Beautiful, correct systems typically demand a high entry fee. They force you to understand their architecture, adopt their mental model, and set up complex environments.

Simple systems meet you exactly where you are. They are easy to install, easy to write, and easy to run, even if they are full of design compromises.

This is often visualized through the concept of a desire path:

A paved path is the "correct" solution. It is planned, concrete, and structurally sound. A dirt path is messy, muddy, and irregular. But people walk the dirt path because it is the shortest distance between where they are and where they want to go.

In software, developers are almost always in a hurry. They will choose the dirt path of implementation simplicity over the paved path of architectural purity.

The Ecological Reality

This phenomenon matches a well-known model in evolutionary biology: r/K selection theory, introduced by ecologists Robert MacArthur and E. O. Wilson.

• r-strategists focus on producing a massive quantity of offspring with minimal investment in each. They adapt quickly to changing, unstable environments.
• K-strategists focus on high-quality, heavily invested offspring. They thrive in stable environments but struggle when conditions shift rapidly.

Software ecosystems are highly unstable, fast-moving environments. They favor r-strategy.

A language or tool that is easy to implement, compile, and port can spread across the internet in a matter of months. It doesn't matter if it is full of quirks. Once it achieves critical mass, the community will write the wrapper functions, build the tooling, and fix the bugs.

The MIT style (K-strategy) spends years polishing the perfect compiler and proving mathematical correctness. By the time it is ready to ship, the r-selected alternative has already captured the market.

The Man Who Argued with Himself

The irony of "Worse Is Better" is that Richard Gabriel spent years trying to disprove his own theory.

Between 1991 and 1992, he wrote a counter-essay titled "Worse Is Better Is Worse" under the pseudonym Nickieben Bourbaki (a play on the collective pseudonym Nicolas Bourbaki used by 20th-century French mathematicians). In this text, Bourbaki acted as a concerned colleague admonishing Gabriel for promoting bad engineering standards.

Later in 1992, Gabriel responded to his own pseudonym with another essay, "Is Worse Really Better?", trying to reconcile his desire for elegant software with the harsh reality of market dynamics.

His internal debate was so intense that his colleagues at Lucid Inc. reportedly grew concerned about his well-being. But despite his best efforts to defend the "Right Thing," the industry continued to validate the New Jersey style.

The Strategic Choice

Recognizing "Worse Is Better" is not an excuse to write sloppy, unmaintainable code. It is an acknowledgment of how systems behave under natural selection.

Unix was flawed. C was dangerous. C++ is notoriously complex. Git's user interface is famously counterintuitive.

Yet, these tools form the foundation of our entire digital infrastructure. They did not win because they were perfect; they won because they were simple enough to implement, fast enough to run, and easy enough to integrate.

When you are choosing how to build your next library, service, or API, you will face this choice. You can build the elegant, theoretically pure architecture that takes a year to design, or you can build the simpler, slightly uglier version that compiles on everything and ships next month.

The paved path is beautiful, but the grass will grow over it if nobody walks it. Sometimes, the dirt path is the only way forward.

Sources & References

• Richard Gabriel, "The Rise of Worse Is Better" (1991): dreamsongs.com/WorseIsBetter.html
• Richard Gabriel (as Nickieben Bourbaki), "Worse Is Better Is Worse" (1991-1992): dreamsongs.com/Files/worse-is-worse.pdf
• Bjarne Stroustrup, "A History of C++: 1979-1991" (1993): stroustrup.com/hopl2.pdf
• Robert MacArthur & E. O. Wilson, "The Theory of Island Biogeography" (1967): Wikipedia Overview
• Git Source Code (wrapper.c): xread Implementation