Better is better

Richard P. Gabriel's Worse is Better is an influential article about why Lisp and its ecosystem, despite many advantages, never became very popular. By the mid-1990's, Lisp Machine manufacturers were mostly dead, and C was the language for operating systems.

The argument is that it's better to have a "mostly-working" system that can be easily and widely adopted, then use the wide adoption to fund later improvements, than to try to design a great system from the outset. Cases in point? C, UNIX, Windows, JavaScript, the list goes on.

Despite its empirical correctness, the idea annoys me, because it's often cited to justify developing a worse solution without understanding the trade-offs. In other words, it's treated as a "Get Out of Jail Free" card by people who don't want to do the work to develop a better solution.

For many things, worse is not better. Better is better, and worse is worse. More specifically, when you don't care about adoption, you should strive to develop the best product possible.

This is often the case with developer tooling. Sure, some tools compete for dollars and market share. Most tools, however, are free products developed by individuals motivated by nothing more than the desire to scratch an itch. For such products, it's much more important to do the "right thing" than to get "something" out there. "Fixing it later" is never a great solution, because it tends to involve thorny issues of maintenance, deprecation, and backward-compatibility.

Why is Emacs is so good? Because nothing is included simply because it "has to be". There's no deadline to meet, no market share to gain, no investors to comfort. Sometimes bad code is included in Emacs, but not for the aforementioned reasons.

As developers, we should recognize and enjoy products that can afford to be better, and do our best to make them so.