Perfect is the enemy of good

People often disregard a technology, language, or service just because it has one or two flaws, usually followed by either "X is better" or "they should have done it better". To me, it comes down to two angles.

Everything has trade-offs

It is easy to find counter-arguments if you know about the alternative proposed, because the truth is that there is no perfect technology, no flawless language, and no universal service. Read, learn, and use enough, and you will always find details that could be improved everywhere.

But let's see three trendy examples:

As of 2023, everyone uses Git to store their source code, except maybe Facebook and their highly adapted Mercurial fork (or perhaps they have also switched by now?). But let's be sincere, Git is as powerful as messy: From time to time, you'll find an article or two mentioning some inconsistency or some limitation (sample). Where it really fails to deliver is in the ease of use: There are so many commands with similar or opposite actions but totally different names, flags and/or parameters, that no wonder why there are so many books and cheatsheets online to learn about the tool. Mercurial, instead, was simpler, consistent, and even a smooth evolution from its predecessor Subversion.

Something more common than Git is Javascript, according to some now the most used language in the world. More than two decades old, and while vastly improved since it originally appeared, it is still a flawed language, as an everyday developer will likely notice, in aspects ranging from Array.includes vs Element.classlist.contains, to the long-lasting battle of CommonJS vs ES Modules, or its performance and memory consumption problems. Not to mention an ever increasingly tricky tooling, or attempts to fix the language (Coffeescript, Dart, Typescript...), or projects to take it outside of the web confines (NodeJS, now also Deno [1]).

Lastly, the transition from XML to JSON is fully completed, and if you attempt to use the former, you'll get raised browns and a lot of questioning. And yet, JSON as a data transport format is nonoptimal! From poor streaming capabilities, to a minimalistic types set (doesn't even know about timestamps!), or almost no mechanisms for data validation (thankfully projects like JSON Schema exist), it is almost as if its only advantage versus XML was extreme simplicity. And it probably is, as now most service communications and APIs use it as the de-facto messaging format despite all the limitations.

So, was Git better than Mercurial? Javascript better than Java applets? JSON better than XML? VHS better than Betamax? Yes, and no. In some sense they are inferior, but they won and conquered their territories, with their flaws and mistakes, and keep evolving.

Seeking perfection is wrong

Seeking perfection can blind you. A perfectionist can spend too much time on small details; meanwhile, a pragmatist will advance way more and way faster. I used to try to be a perfectionist, and I would never finish any personal project. Now I plan small incremental iterations, and feel way happier to have quite a few things, and scripts, and small web projects, here and there; most if not all in a decent state to fulfil their original purpose.

And at your job, if you are an engineer, often you are not paid to craft the single best and most flawless piece of software; You get paid to generate value, to the business and often to its users. If you get pride boosts along the way because you do something awesome, great and congratulations! But it would be best if you prioritize delivering new or better things, not perfect things. Note that it does not mean "shipping fast" if doing so would hurt quality (or waste resources needlessly), but that's a topic maybe for another post.

I've seen a few times teams wasting time building "their better XXXXX" instead of using the stock alternative (often open-source). Or even better, use that open-source system and try to add improvements and contribute back some of them (It's not always possible, though). If you include the time factor, I bet you could often steer away projects from a "Do It Yourself" approach to a "let's use what's available, as long as it is good enough".

Don't let perfect be the enemy of good

[1]: Fun fact: Deno is, to my knowledge, from one of the creators of NodeJS, and mainly originated to fix many of NodeJS mistakes, which apparently are pretty hard to solve nowadays due to its decision-making system. I found this podcast episode quite interesting to learn about the whys.