The Case for Boring Technology

Every few months, a new JavaScript framework arrives with a manifesto and a promise. It will be faster. It will be simpler. It will solve the problems created by the last framework, which also arrived with a manifesto and a promise.

I have shipped production software with a dozen different stacks. The ones that aged well were not the ones that used the newest tools. They were the ones that used the most boring ones. PostgreSQL. Express. Plain CSS before it was cool again. Tools whose behaviour you could predict because they had been around long enough to be understood completely.

The Cost of Novelty

Every new technology you adopt carries a tax that is not visible in the first week or the first month. It becomes visible in month six, when you discover a bug in the framework and the GitHub issue has been open since last year with no resolution. It becomes visible in month twelve, when you need to upgrade to a new major version and the migration guide is forty pages long.

Novelty is not free. You pay for it with debugging time, with documentation gaps, with the slow realisation that the elegant abstraction you fell in love with does not actually map to the problem you are trying to solve. Sometimes this tax is worth paying because the new tool genuinely solves a problem the old tools cannot. Most of the time, it is not.

What Boring Buys You

Boring technology has two virtues that are undervalued in engineering discourse: predictability and institutional memory. When you build on PostgreSQL, you can hire people who already know PostgreSQL. When you have a problem with PostgreSQL, someone else has already had it and written about it. When you need to scale PostgreSQL, there are well documented paths that thousands of teams have followed before you.

This does not mean you should never adopt new tools. It means you should adopt them deliberately, with clear understanding of what you are trading away. The right question is not whether a tool is better. It is whether the improvement justifies the loss of predictability, community knowledge, and operational experience that comes with maturity.

A Framework for Choosing

When evaluating a technology choice, I ask three questions. First: can I explain how this tool works under the hood, or is it magic to me? If it is magic, I cannot debug it effectively when it breaks. Second: if the maintainers abandoned this project tomorrow, could my team continue to use it safely for two years? If the answer is no, the tool is a liability, not an asset. Third: does this tool solve a problem I actually have, or a problem I wish I had? Many teams adopt technology for the scale they aspire to rather than the scale they actually operate at. The boring choice is rarely the wrong choice.