On Tools and Popularity
An overengineer once said:
There are only two kinds of languages: the ones people complain about and the ones nobody uses.
This is not quite right, or is at least incomplete. More accurately:
There are only two kinds of software tools: unpopular ones and misused ones.
A software tool will either be unpopular, or mis-used in 99% of cases.
Unpopularity is not so bad. Unpopularity does not mean “unused”. It means that nobody outside of the circle of people for which the tool was built uses it. That is okay. Not every tool needs to choose between “gets so popular that Dan Abramov obsoletes it with something overcomplicated and inferior”, and “checked into the nice hospice by the park Apache Software Foundation”. There is a third option: tools that serve a bounded community well and are content with that.
But popularity? Popularity is a problem. A popular tool will be mis-used a lot, in ways ranging from infuriating to unethical. What’s worse, the [mis-]users will insist that their mis-use is either not mis-use, or that it should not be mis-use and that the tool should be changed to make the consequences of mis-use less severe. Given a sufficiently sizeable community, antipatterns turn into roadmap goals.
This is true for Open Source tools, closed-source tools, and internal tools. The internal version of this story goes:
We created a REST API platform for internal teams to use when communicating with each other, but they refuse to adopt it unless we add ad-hoc RPC features which facilitate … the thing we created the API platform to get away from.
The open source/public version of this story goes:
REST is actually a very specific standard. However, it is extremely rigorous-née-dogmatic (which word you prefer depends on your business context/needs). As a result, almost nobody complies with the vast majority of what defines REST behavior, though they’re more than willing to mis-use the term “REST” to apply to whatever they built instead.
Both cases cause semantic confusion and conceal the underlying reality: truly RESTful behavior requires discipline and compromises–resources in short supply in many software enterprises.
REST is an easy punching bag, but this popularity crisis afflicts nearly all software tools to some degree (1)Example: I know GraphQL can be typed, but is the GraphQL API you use at your day job typed? Are the typings accurate? Useful? Yeah, that’s what I thought. If you still retain any optimism in your heart of hearts (this is commonly referred to as “being a junior engineer”), consider that the second list item for the Google search “best GraphQL APIs” is “Blockchain data”. .
Fighting the tide of mis-use becomes exhausting and untenable. Many tool authors very reasonably opt to walk away. Most of those who remain follow the “if you can’t beat ’em, well, maybe the real lessons were the problems you caused along the way!” approach, and so good tools are replaced with antipattern-as-a-service (abbreviated “ASS”, no I will not be taking questions at this time) systems.
Tools that attempt to get out of this gravity well via -ng-suffixed rewrite are, by and large, doomed unless sufficiently popular to reach escape velocity.