Worse is better by Mark Seemann
The most popular technology may not be the best.
In 1989 Richard P. Gabriel coined the term Worse is Better, a clearly humorous take on certain tendencies in software development and design as he saw them. I first encountered the term in his book Patterns of Software, and I'm basing the following on that.
In essence, another way to state the epigram is that perfection is the enemy of the good. Gabriel's context was the juxtaposition of Lisp versus C++. Gabriel had founded Lucid, a company that offered a general-purpose, cross-platform Lisp compiler, only to see C++ becoming the de-facto cross-platform programming language. The Lucid people considered Lisp superior, and were casting for an explanation why the inferior product was winning.
It's not my agenda to repeat Gabriel's entire line of reasoning. Rather, I want to highlight other areas of software-development technology where a similar relationship exists: A superior technology or process has lost to a more popular alternative.
Of course, any comparison between two technologies is likely to be subjective. My aim is not to insist that technology x is indisputably superior to the more popular technology y. Rather, my purpose is to give you food for thought. If you are a software architect, or other technical decision-maker, being aware of alternatives is useful. Often, going with the most popular tool is appropriate, but sometimes it may be prudent to at least consider alternatives.
In a series of articles, I will give specific examples. None are intended as rage bait, but rather as food for thought. The purpose is to highlight that the popular choice may have properties that are inferior to a less popular alternative. While I'm aware of the strengths of the popular choice, in this series I will instead highlight the advantages of less popular alternatives.
- Worse is better: JSON versus XML
- Worse is better: C# versus F#
- Worse is better: async/await versus syntactic sugar for monadic composition
When I publish this overview article, the above table of contents will initially be short, but I plan to expand it as I go.
Benefits of the road less travelled #
There are reasons that the most popular technology occupies the top spot. Often, those reasons apply to your case, too. If so, do go with the popular option. Consistently going against the flow is a recipe for misery.
Even so, you may occasionally run into a situation where the less popular alternative offers a benefit that outweighs what the mainstream choice offers. Perhaps the popular technology has properties a, b, c, d, and e, while an alternative is clearly superior when it comes to property f. If f is important enough in a certain context, you may decide to choose the road less travelled. That's a simple cost-benefit analysis.
Another advantages of going off the beaten path is the flexibility and freedom it may entail. In my experience, popular technologies are often associated with strong ecosystems. This is clearly a strength, but can also become a liability. Mainstream ecosystems tend to railroad you into a particular way of doing things. As long as your work matches the idiomatic way of doing things, you may be coasting along fine. On the other hand, if you need to do something exotic, you may find that the mainstream way of doing things makes your work harder. Examples could include using ORMs instead of writing plain SQL, or using Postman instead of curl.
Choosing a technology with a lesser ecosystem may force you to forge your own path. It seems that this could only slow you down, but there's also the chance that it enables you to respond better to unplanned events. It might even give you a trace of antifragility. It may help you escape vendor lock-in.
Conclusion #
A technology, a programming language, a protocol, or a tool is often popular because it's better than most alternatives. That said, software development is such a multifaceted endeavour that it's absurd to talk about a single best option. Even assuming that you can quantify every aspect of developing software, the notion of anything being the best assumes a total order, which is unreasonable in such a multidimensional space.
Thus, even if a technology is generally 'better' along commonly-considered axes, it's likely that some other technology is better for specific tasks.
Even so, some popular technologies are popular for reasons that aren't entirely well-considered. Or, for one overwhelming reason that, once you start to think rationally about it, shouldn't be such a big deal as it seems to be. Gabriel thought that C++ was inferior to Lisp, but essentially won in the marketplace because it was possible to release and support an inconsistent language incrementally, whereas, if I understand the story right, Lisp was more an all-or-nothing proposition that never really came to fruition.
In the following articles, I'll discuss some technologies that are generally worse than their less popular alternatives.
Next: Worse is better: JSON versus XML.
