Neomania in Software

Programmers love to use new technologies. They get a hit of dopamine from reading shiny new documentation and trying out new programming languages. They think of themselves as pioneers, using new tools as their competitive advantage over the less adaptable competition. “Those boring old programmers, not using this new tool, don’t stand a chance,” they think to themselves while grinning into their ultra-wide 4k monitors. Old tools remind them of their grandparents, slow and set in their ways. Doing what everyone else does goes against their desire to stand out from the crowd, to be the hidden gem, the David to the mainstream’s Goliath. Their desire to use the shiny new thing is strong. So strong, that it overrides their ability to evaluate it objectively.

They immediately jump to the illogical conclusion that newer means better. Placing a higher value on how the new thing makes them feel rather than its technical merits. If an equivalent technology existed with the same feature set but a 10-year-old release date, they’d be disinterested. This illogical obsession with the “shiny new thing” is called Neomania. It’s why people break the bank for the new iPhone each year despite there being a marginal difference from the previous model. And it’s an affliction that all programmers suffer from at some point.

Neomania is illogical because it fails to acknowledge the immense value that comes from age and popularity. The older and more popular a technology is, the more it’s been tested against reality. In the context of software this means more problems have been solved with it, more bugs have been found and fixed, it has more integrations with other pieces of software, and it has more Stack Overflow questions and answers related to it.

Age * Popularity = More features, fewer bugs, more integrations, and more documentation

When compared to their older and more popular counterparts, newer, less popular technologies have fewer features, more bugs, fewer integrations, and less documentation. So before you re-write all your code in that new functional language that ranked first on StackOverflow’s list of most loved languages, ask yourself if sacrificing features, integrations, and documentation is worth the trade-off.

Time is the ultimate filter. For both ideas and technologies, It exposes the weak and reveals the strong. Sure, a bad idea or a lesser technology can be successful for a short time under the right, lucky circumstances. But sustained success is no coincidence. Especially in a landscape as competitive, popular, and fast-paced as software. If a new technology emerges that is cheaper, faster, and better than the current technology, it will replace it. Embedded in this truth is the fact that existing popular technologies have maintained supremacy over hundreds, if not thousands of competitors, that have tried, and failed, to replace them. But we only see the survivors.

As time passes, existing technologies amass more features, more integrations, and more documentation. Making them harder and harder for emergent competitors to eclipse. Further increasing the likelihood that the oldest, most popular technology, will continue to reign supreme. This phenomenon is known as the Lindy Effect, which states that a technology’s future life expectancy is proportionate to its current age. The Lindy Effect is why Unix-based operating systems, which have been around since the 70s, aren’t going anywhere anytime soon. It’s also a great heuristic for choosing your tech stack. The oldest in-use tool has the highest future life expectancy. It’s much less likely to become unmaintained than newer, less popular alternatives. So when in doubt, choose the old boring thing. Write your backend in Python and use a PostgreSQL database. Ignore your inner Neomaniac.

One of the main reasons otherwise brilliant programmers fall into the trap of Neomania is clever marketing ploys from creators and evangelists of new technologies. One particularly effective technique these groups use is emphasizing the importance of some deficiency with the more established technology and using that deficiency as justification for throwing out the baby with the bathwater. “Python is too slow, you need to use a more performant, statically typed language like X.” “Writing SQL queries takes too long, you should use a schema-less NoSQL database like Y to move faster.” Don’t blindly accept the premise of the problems new technologies promise to solve. Honestly ask yourself if the stated problem is one that you actually have and whether solving it justifies the risk, time, and effort of adopting the new technology. Python is 10-100 times slower than Go depending on the computation you’re performing. But if your app is already fast enough, investing time in a rewrite to make “fast enough” 100 times faster doesn’t make sense. Your users can’t tell the difference between 100ms and 1ms.

At the end of the day, all that matters is how the tools and technologies you use contribute to the product you're building and the speed at which you can iterate on that product. If it doesn’t affect that bottom line, it doesn’t matter. Your users don’t care if you used the latest and greatest programming language or database or text editor or project management tool. They care about the thing they interface with. They care about the product. Decisions to use tools or technologies that don’t affect the product don’t matter. And technology decisions that risk the quality of that product or the speed at which you can build it just because you want to use the shiny new thing, don’t make sense. If you’re at the bleeding edge, expect to bleed a lot. But keep in mind that your users don’t care how much you bled. They only care about the product.