When selecting which languages to learn, which technologies to adopt, and which libraries to use in your project, evaluate them on merit, and not on how fashionable they are.
A tempting idea is that popularity is a good proxy for merit. In general, it is not. There is a famous quote[1] that goes “the best argument against democracy is a five-minute conversation with an average voter”. The same logic applies to evaluating technologies. Most people do not do this well. It’s not that they are incapable of doing so, it’s just that it takes a considerable amount of effort to do well.
There’s another scary parallel to the political process — opinion can be bought with money. Driven by the startup approach to building product, and VC dollars to use for marketing, some technology vendors hype up early, not production-ready version of their software, in order to get adoption, followed by vendor lock-in, and hoping to buy themselves time to get the software production-ready by the time locked-in customers face scalability and reliability issues. There is some evidence that this is in part what fuelled the “SQL is dead, use NoSQL databases” for everything movement.
Another frequently used process for convincing people to adopt a technology is “look, it takes n lines to build a TODO app in this”. Simplicity for a tiny, artificial use case, is rarely a good predictor of a technology’s performance in the real world. Just like with the NoSQL[2] case — yes, it is easy to just dump the data into a JSON blob, but this ignores a huge number of issues that production apps face as they grow, and let’s face it, most people will not transition to a better store as the app matures, they will try to incrementally evolve their NoSQL solution as the issues arise one at a time, digging themselves further into a whole.
Simple examples that push the “number of lines” argument are usually dangerous. They force the author to focus on the wrong metric. I’ve yet to see a technology that makes an argument “you can build a TODO app in n number of lines, while having clean architecture to support this list of real-world requirements that any beyond-prototype app faces”. In a world where most technologies scream loudly with reality-ignoring crowd-pleasing arguments, it’s difficult to be an outlier and cater to real use cases in your marketing material.
It’s just like politics.
Incidentally, having a “vibrant, active community” is also not a good indicator of quality. The converse is a good signal for avoiding a technology — if it has no community, it’s likely a dead end. But having a vibrant community is not good signal in itself. Javascript had a vibrant community, most of them producing and publishing abysmal quality libraries, leading to bloated, slow apps full of security vulnerabilities. The “anybody can and does publish code” model lead to the dangerous “just use a library for that” approach which is great for prototyping, but poor for building production software. Besides, vibrant communities tend to be loud, and “saying something loudly” in a social situation is often close to being the opposite of “saying something meaningful”.
Actively following the goings on of the technology world is also not worth doing. You’ll be reading about this or that new library every day, but this is all mostly noise. The amount of value you’ll derive from following various random releases is limited. Truly meaningful technological changes don’t happen overnight, and you’ll hear about them even if you don’t keep up daily.
[1] Often misattributed to Winston Churchill. See, now even though I said “misattributed”, I bet you have the quote firmly linked to Churchill in your mind, the link will persist, while the “misattributed” property on the link will fade. Memory is a funny thing.
[2] In case it isn’t clear, I’m not arguing that NoSQL is bad across the board. It has its uses. But they are limited and very domain-specific. Just like the answer to “do you need blockchain in your product” is “if you’re asking, no”, similarly the answer to “do you need NoSQL in your project” is “probably not”.
Comments
Post a Comment