The Case for Boring Technology
Novelty has a running cost that never appears on the ticket. A look at how we decide when a new tool is worth its weight.
Every team gets the same offer several times a year. A newer database, a faster runtime, a framework that promises to remove a category of work. The demo is convincing. The migration is scheduled. Eighteen months later, someone is maintaining a bespoke adapter that only one person understands.
New tools are borrowed against future attention
The cost of a technology is not the time it takes to adopt. It is the attention it will demand for as long as it stays in the stack: the upgrades, the edge cases, the on-call incidents at an hour when the documentation is thin and the community is asleep.
Boring technology has already paid that cost down. The failure modes are known. The error messages are searchable. When something breaks at two in the morning, someone has broken it before you and written about it.
Choose boring for the parts of your system that must not surprise you, and spend your novelty budget where the surprise is the point.
A budget, not a ban
This is not an argument for stagnation. It is an argument for spending deliberately. We allow ourselves a small number of unfamiliar technologies at any one time. Everything else defaults to the thing we already run in production.
When something new is proposed, we ask four questions:
- What does this let us do that we genuinely cannot do today?
- Who on the team will own it in a year, by name?
- What happens if the maintainers stop?
- How do we get back out if we are wrong?
A proposal that survives all four is usually worth it. Most do not survive the second.
The exit plan matters more than the entry
We have never regretted a tool we could remove in a week. We have regretted every tool that quietly became load bearing before anyone decided it should be. The practical test is whether the integration sits behind an interface we control. If it does, replacing it is an afternoon. If it does not, it is a quarter.
The reward is a quiet system
The best outcome of this approach is that nothing interesting happens. Deploys are dull. Incidents are rare and familiar. The team spends its energy on the product rather than the platform underneath it.
That is not a lack of ambition. It is where the ambition goes when it is not being spent on infrastructure.
