The case for boring technology
Every new tool spends a little of the team's attention. Spend it where it buys something.
Innovation tokens
Every team has a limited amount of attention to spend on unfamiliar technology. Each new database, framework, or deployment model consumes some of it: people need to learn how it behaves, how it fails, and how to debug it at two in the morning. Spend that budget on the things that differentiate your product, and choose well understood tools for everything else.
What boring buys you
A technology becomes boring when its failure modes are known. Thousands of teams have already hit the strange edge cases, written about them, and patched the worst ones. Search for an obscure error message and you find an answer. That is an enormous, invisible productivity gain.
Boring tools also make hiring easier, documentation better, and onboarding faster. A new engineer who already knows the stack contributes in their first week rather than their second month.
When new is worth it
This is not an argument against ever adopting anything new. Some problems genuinely need a different tool, and some new tools are dramatically better than what came before. The question to ask is narrow:
- Does this solve a problem we actually have today?
- Is the improvement large enough to pay for the learning curve?
- Can we contain it, so that if it disappoints we can remove it?
If all three answers are yes, the new tool is probably worth the attention.
The hidden cost of variety
Two databases are more than twice as hard to run as one. Each needs backups, monitoring, upgrades, access control, and someone who understands it deeply. The same is true of languages, message queues, and frameworks. A small team with five of each is spending most of its operational energy keeping the variety alive.
Consolidate deliberately
Periodically list every distinct technology in production and ask which ones could be retired. Often a feature built on an experimental store can move to the main database with a few days of work, removing a whole category of operational burden.
Boring is not the same as old
Some mature tools are poorly suited to modern needs, and clinging to them is its own risk. Boring means predictable, well documented, and widely understood. It does not mean unmaintained.
The payoff
Teams that choose boring infrastructure ship more of what customers notice. Their incidents are shorter because the failure modes are familiar, and their engineers spend their curiosity on the product rather than on the plumbing.