Every few months a new database, framework or deployment tool arrives with a polished website and a crowd of early fans. The demos are fast, the documentation is friendly, and the old tools in your stack start to look tired by comparison. Picking up the new thing feels like progress.
Sometimes it is. More often, the new tool solves a problem you did not really have while quietly creating several you did not expect. This piece makes the case for the dull, well-understood software that most teams already know how to run, and for choosing the exciting option only when it clearly pays for itself.
What “boring” actually means
Boring software is software whose behaviour is well understood. That usually means it has been around for years, lots of people run it in production, and most of the ways it can fail have already been found, written about and fixed. A mature relational database, a long-established web framework, a plain message queue: these are boring in the useful sense.
Boring does not mean bad or outdated. Many boring tools are still actively developed and perfectly capable of running large systems. What makes them boring is that there are few surprises left. When something goes wrong at two in the morning, someone has almost certainly hit the same problem before, and the answer is a search away.
New tools are the opposite. They may be excellent, but their failure modes are still being discovered, often by the people using them in production. When you adopt one early, you volunteer to be part of that discovery.
The hidden cost of each new technology
The visible cost of a new tool is the time it takes to learn and set up. That part is easy to estimate and usually small. The larger costs arrive later and are spread across the whole life of the system.
Operations and failure
Every technology in production needs to be deployed, monitored, backed up, upgraded and debugged. Each one has its own configuration, its own logs and its own ways of misbehaving under load. A team that runs one database has to understand one set of failure modes deeply. A team that runs four has to understand four, usually less deeply.
That spread matters most during incidents. Diagnosing a slow query in a system you know well might take minutes. Diagnosing the same symptom in a tool nobody on the team has run before can take days, and the fix may depend on a bug report that the maintainers have not yet answered.
People and knowledge
New tools also carry a people cost. Hiring is harder when fewer engineers have used the technology. Onboarding takes longer. Knowledge tends to concentrate in the one or two people who championed the tool, and when they move on, the team is left maintaining something few of them understand.
There is an integration cost too. Your existing tooling for deployment, testing and monitoring was built around the technologies you already use. Each new one needs its own adapters, scripts and workarounds, and those pieces of glue become software you have to maintain.
Setup and learning time, which is usually visible and modest.
Ongoing operations, including monitoring, upgrades and backups.
Slower diagnosis when things fail, especially under pressure.
Hiring and onboarding friction.
Integration work to fit the tool into everything else you run.
Innovation tokens
The clearest statement of this idea comes from Dan McKinley’s 2015 essay “Choose Boring Technology”, written from his experience as an engineer at Etsy. It has become one of the most widely shared pieces of writing on the subject, largely because it gives teams a simple way to talk about a trade-off they already feel.
The essay’s central device is the innovation token. Imagine that a company gets a small, fixed number of these, roughly three in his telling. Each time you choose something new and unproven, you spend one. Tokens are limited because a team only has so much attention for learning, debugging and operating unfamiliar things. Spend them all on infrastructure experiments and there is none left for the parts of the business that actually need new ideas.
The essay also argues that technology choices should be made at the level of the whole system, not tool by tool. Adding a new data store might look sensible in isolation, but the real question is whether the combined cost of running it alongside everything else is worth what it adds. Often a slightly awkward solution using tools you already run is cheaper overall than an elegant one using something new.
The best tool for one problem is not always the best tool for the company that has to run it for the next five years.
The argument leaves plenty of room for new tools. What it asks is that teams spend novelty deliberately, on the places where it makes a real difference, and being honest that every new tool draws on a limited budget of attention.
When a new tool earns its place
New technology is sometimes exactly the right choice. The question is whether it does something your existing tools genuinely cannot, or can do only at unreasonable cost.
A few signs suggest that a new tool has earned a token:
It solves a problem that sits at the heart of what your product does, so doing it better is a real advantage.
You have tried to solve the problem with what you already have and can point to specific, measured limits.
The team is willing to own it for the long term, including the unglamorous parts like upgrades and on-call.
You can remove it later without rewriting everything if it does not work out.
The first point is the most important. A company whose product is real-time collaboration might reasonably spend a token on an unusual synchronisation technology, because that is where its value lies. The same company probably should not spend one on a novel way of sending password-reset emails.
The second point guards against a common pattern: adopting a tool because it is supposed to be faster or more scalable, before anyone has checked whether the current system is actually too slow. Many performance problems turn out to be a missing index or a badly written query, fixable in an afternoon with the tools already in place.
Choosing on purpose
Most bad technology choices are not the result of careless people. They happen because nobody made the choice explicitly. One engineer tries a new library on a side project, it creeps into production, and a year later it is load-bearing.
Make the default visible
A simple fix is to write down your defaults. A short list of the languages, databases, queues and hosting options the team considers standard makes the boring choice the easy one. Anyone can still propose something different, but they do so knowing what they are departing from.
Write the proposal down
When someone wants to add a new technology, ask for a short written proposal. It does not need to be long. It should say what problem the tool solves, what was tried first, what it will cost to run, who will own it and how the team would back out. The act of writing this down often settles the question, in either direction.
It also helps to separate enthusiasm from evaluation. Engineers are drawn to new tools for good reasons: learning is enjoyable, and working with modern technology is good for a career. Those motives are legitimate, but they are better served by time set aside for experiments and prototypes than by quietly shipping the experiment to customers.
Living with the decision
Choosing a boring stack is a habit that has to survive pressure, and a single good decision at the start will not hold on its own. There will always be a new tool that looks better on paper, and a conference talk showing how another company used it to great effect.
Consider Marta, an engineering lead at a 25-person company that sells scheduling software to dental clinics. Two years ago her team ran a single relational database, one web framework and a hosted job queue. Over eighteen months, three well-meaning engineers each added something: a document database for a reporting feature, a separate search engine, and a new streaming system for notifications. Each choice made sense on its own.
The trouble came in the incidents. A notification delay turned out to involve the streaming system, which only one engineer understood, and he was on holiday. The reporting database fell behind on upgrades because nobody felt responsible for it. Onboarding a new developer now took weeks instead of days.
Marta did not rip everything out. She asked the team to list every technology in production, who owned it and what it would take to remove. The search engine stayed, because it did something the relational database could not do well and the team had come to rely on it. The reporting data moved back into the main database, where a few well-chosen indexes handled the load. Notifications went back onto the existing job queue. The team ended the year running fewer things, and running them better.
That kind of review is worth doing periodically. Technologies that earned their place still deserve a token, and should get proper investment in documentation and shared knowledge. Ones that have not can often be retired, which frees attention for the work that matters.
A quieter kind of progress
There is a certain satisfaction in running software you understand completely. Upgrades are routine. Incidents are diagnosed quickly. New team members become useful sooner, because the tools are ones they have met before. Time that would have gone into learning the quirks of a new system goes into the product instead.
None of this rules out ambition. The point is to be ambitious in the right place. Keep the foundations dull and dependable, spend your few innovation tokens where they give your product a real edge, and write down why you spent them. That way, when the next shiny tool arrives, you have a calm way to decide whether it belongs.
Written by
Tomás Reyes
Tomás writes about the software and hardware people actually use. He used to build billing systems, and still has opinions about them.
