Inferior is Better

One time, in jest, I said the following:

This is how you know Racket is a production tool meant for real software engineers, whereas the [Racket] student languages are obviously not. If it can’t generate confused S[tack]O[verflow] posts, it doesn’t really exist in the professional’s mind. Without struggle, there is no triumph.

But I wasn’t really joking.

Over the years, I’ve come to feel that slightly inferior technologies are better—not in the Richard Gabriel sense of Worse is Better, but rather because they create communities (of support and help) and ecosystems (of tools). It’s my own theory of (not-better)-is-better and, to avoid confusion, we’ll call it Inferior is Better.

My context, most specifically, is related to software. But I suspect this applies to many other engineered objects as well.

Software that is better in principle comes with everything you need. Software that is inferior does not, and someone has to fill it in. They do it by building tools.

Every third-party “tool” is actually a weakness: it’s doing something that either didn’t need to have been done at all, or could have been done better in the first place. However, it creates a community. There’s a way for people to contribute. It’s like a game that leaves little bonuses lying around for people to pocket. If even a novice can make a small contribution, so much better. They feel good about themselves, and now they’ve made a commitment to that ecosystem. The switching costs suddenly became significantly higher.

In the realm I know best, programming languages, this is especially true. And in fact, to be “successful” in terms of size, perhaps every language should start out somewhat flawed: it should have bad scope rules, weird modules, funky overloading, floating points as the only numbers, and so on. To a rational observer, this might seem an awful idea. But programmers, as a species, have gotten acculturated to salt mines as a natural habitat. They will think nothing of it. I’m also reminded of this quote from the inestimable Bob Boyer himself:

One wag remarked about VHDL that the word “entity” is used in about 9 different ways in the LRM! I think one should simply go laugh about such things, and maybe decide which VHDL or Verilog vendor in which to go buy stock.
—Robert S. Boyer, 1996-09-21

Of course, you need something to draw them in: “one weird trick” that lets them do entirely unnecessary and perhaps wholly unwise things that let them demonstrate virtuosity. The latter draws them in, and the former seals the commitment. One could view C++ templates as a form of the latter.

Johan Jeuring pointed out the Service Recovery Paradox, which is certainly related. In this, customers regard more highly an organization that has recovered well from failure than one that had not yet failed. Good designs are like the latter: they do not fail, and therefore cannot pleasantly surprise you. Inferior designs fail, but when the community comes to your rescue, you are left happier than you were before.

If all this is rather sobering to the nascent language designer, all they need to remember is that the game changes entirely if you alter the metric away from the size of your userbase.