📕 Node [[worse and when how it can be better]]
📄 Worse--and-when---how-it-can-be--better.md by @enki

Worse, and when & how it can be ‘better’

Richard Gabriel’s essay ‘Worse is Better’ is used to excuse a lot of bullshit, in ways that Gabriel would not endorse (and in ways that…


Worse, and when & how it can be ‘better’

Richard Gabriel’s essay ‘Worse is Better’ is used to excuse a lot of bullshit, in ways that Gabriel would not endorse (and in ways that conflict with the explanations Gabriel himself gives). This is probably because, like other damaging slogans such as “move fast and break things” and “it’s better to beg for forgiveness than ask for permission”, it’s short and catchy enough to spread well beyond the context in which it’s valid advice.

“Worse is Better” does not argue that bad things are automatically good, or that poor design has an inherent advantage over good design. Instead, it argues that in particular circumstances, the necessity of nuance hinders or slows widespread adoption. It is relatively rare that widespread adoption is desirable, so this phenomenon is usually irrelevant.

I have recently heard people claim “worse is better” is the reason that:

  • the Web won over Gopher
  • the Web won over Xanadu

I have heard both things from the same person, even though they use essentially contradictory interpretations of the essay. (Both are based on common, yet anhistorical, myths. In fact, Gopher was doing just fine until an attempt to enforce trademarks, and Xanadu has been plagued by management problems.)

Here are some situations when ‘worse’ can be ‘better’:

  • A commercial product with a shallow initial learning curve may attract a greater number of casual users than one with a steep initial learning curve, even when the latter is preferred by serious users.
  • A commercial product that takes a long time in early design phases may be beaten to market by another product that was not as carefully considered, and if their runway is insufficiently long they may go out of business before releasing a better product.
  • A system may have inertia from a large user base, and that inertia may slow the adoption of a different system that is less familiar, or it may make it difficult to gain widespread support for large-scale changes.

In all of these situations, ‘better’ belongs in scare-quotes:

  • Serious users are willing to spend more money on good software, and casual users are fickle, so a steep initial learning curve is a good business strategy if it makes the tool more powerful (and if sufficient effort is put into documentation and educational resources).
  • It’s not worth selling a product you know is bad, even when it makes you a lot of money — people who do this are called scam artists.
  • Exercising intellectual integrity pays off big when the neophobic portion of your user base dies off, leaves, or becomes outnumbered by people who appreciate a well-designed system. FORTRAN and COBOL may still be in use, but of that cohort, only LISP still retains a good reputation fifty years on — the rest of the legacy code is largely not by choice.

The web did not win over gopher because ‘worse is better’: a complete gopher client or server can be written by a beginner programmer in an afternoon, while web servers look like Apache (or, at best, like lighttpd) and web browsers look like Chrome (or, at best, like dillo) — gopher is conceptually simpler, has a shallower initial learning curve, and supports all of the useful features of HTTP. Even if it did, that wouldn’t justify the win — it would merely be another tragedy.

When ‘worse is better’ actually applies, it highlights the ways in which accidents of history occasionally deprive us of greatness. Rather than using it to justify giving up on quality, we ought to rectify the situations in which it occurs.

By John Ohno on November 16, 2018.

[Canonical link](https://medium.com/@enkiv2/worse-and-when-how-it-can-be- better-930ced76acea)

Exported from Medium on September 18, 2020.

Loading pushes...

Rendering context...