Choose Boring Technology (2015)
TL;DR
Dan McKinley says a company gets about three "innovation tokens" to spend on unproven technology. Everything outside its core problem should run on "boring" technology whose failure modes are already known. Adding a new technology should be a deliberate decision for the whole company. Over the years, running many technologies costs more than picking the best local fit saves.
The article
- Every company gets roughly three innovation tokens. Choosing NodeJS, MongoDB or year-old service discovery spends one each. Writing your own database spends more than you have.
- Boring does not mean bad. MySQL, Postgres, PHP, Python, Memcached and cron are boring because people know what they can do. More important, people know how they fail. New technology carries far more unknown unknowns.
- "Best tool for the job" thinking is short-sighted. Every added technology needs its own monitoring, tests and init scripts, plus room in people's heads. Over a system's life, keeping it running costs far more than any inconvenience while building it.
- Before adopting something new, ask how you would solve the problem with the current stack. Write down why that is too hard. Then commit to migrating off whatever the new technology replaces. This exposes the cases where the real goal is just to use the technology.
- Etsy's activity feeds ran on PHP, MySQL, Memcached and Gearman. They scaled 20x over several years with nobody dedicated to them, because they sat on the shared platform. An earlier Python middle layer took years to remove.
- Letting every developer pick their own language is sold as productivity. In practice it buries the team in operational toil. Holding back on technology frees engineers for bigger questions.
Why it matters
Read the original if you make stack decisions. The Etsy war stories live in the footnotes. The essay also lays out a lightweight review process for adding technology that this summary only sketches.
The discussion
A large thread, mostly fond of the essay as a classic. Its longest exchange is a fight over whether "boring" is a useful heuristic or a vague slogan that ends discussion. People also argued over whether Node and Kubernetes count as boring now and how AI coding agents change the math. Others asked why incentives push engineers toward shiny technology.
Is "boring" a useful heuristic or a vague proxy?
insanitybit argued across dozens of replies that "boring" is a weak stand-in for the real criteria: well tested, understood by the team, fitting the requirements. simonw, jonahx and others answered that the word counters engineers' bias toward the new, since it is easy to invent reasons shiny technology fits. The tokens idea, they said, stops a project from stacking several unproven bets. A few agreed with the critique and said the slogan shuts down more conversations than it opens.
Any productive conversation that starts with (1) immediately has to follow "can you clarify what that means", so the term is useless at best and thought terminating at worst.
Because people LOVE COMING UP with excuses to try a new technology under the basis that "this is appropriate for our use-case", and if you don't introduce a concept similar to innovation tokens you may find that six months later your project is combining three different unproven new technologies and doesn't actually work yet.
Boring is relative to your team and to time
Boringness depends on your team and on timing: Node was shiny in 2015, and most now call its runtime boring. Its npm ecosystem and the tooling churn across Bun, Deno, pnpm and linters still feel risky. Kubernetes split the thread between "boring after 12 years" and "a boat anchor for most shops". One data engineer pointed out that three engineers could each name a different "most boring" pick among pandas, PySpark and Polars.
Boring isn't a universal trait, it has to be evaluated within the context of your own team.
I think a good metric for "boring" technology, at least for languages/frameworks, is how painful the process of updating an abandoned/unmaintained project after 9-12 months is. NodeJS itself qualifies as boring, but the entire ecosystem around it is still a mess.
AI agents and the case for in-distribution tech
Several said agents strengthen the essay's case, so innovation tokens should go to agents, working on boring stacks common in training data. An LLM's fluency in a mainstream language, they argued, outweighs small technical advantages elsewhere. Others thought AI makes PHP attractive again, a language unpleasant to write but simple to operate, or favours Go for its stable conventions. Skeptics answered that agents lean toward whatever was popular in training data, mostly TypeScript and Next.js, rather than what fits, and bring their own risks.
The amount that Zig is better is going to get swamped by the amount that in-distribution agents are better.
But if AI writes most of the code? Suddenly PHP becomes an excellent candidate to choose for many use cases.
Simple infrastructure beats cloud complexity
A cluster of commenters said most businesses could run on a couple of bare-metal servers or a cheap VPS. Résumés and budgets drive multi-cloud Kubernetes more than need does, they said, and asa400 blamed engineers who weigh hardware savings above their own time. Developers in large organisations pushed back, since for them AWS is mostly a way around internal procurement. One suggested a third machine to avoid split-brain during failover.
2 bare-metals with Linux, Postgres, HAProxy and PHP (or Python/Django) work perfectly fine for 99% of apps that businesses need.
Ok, but your team’s total comp is costing the company on the order of $1MM/year. Is saving $1,600/month on infrastructure to spend $20k/month on dev time a good deal?
Incentives and war stories
Commenters blamed engineers' dislike of the essay on career incentives, since new technology builds a résumé and reliability work goes unseen until it fails. Firsthand stories cut both ways: one company still struggles to hire for a Scala codebase its authors left behind. Another team pushed its in-house Cassandra cluster onto workloads it never suited, because Cassandra was the "boring" choice. Some objected that "CV-driven development" assumes bad motives when people are usually just excited to build.
Managers and employees are rewarded for popular thing. Popularity is mostly a function of novelty. So the (social and therefore economic) incentive structure is inversely correlated with choosing boring technology.
Sometimes boring technology isn't enough, you also need boring workloads for it.
Consensus
Most agreed the core advice still holds a decade later. Limit the number of unproven bets and prefer technology whose failure modes your team already knows. Weigh operational cost above local fit. The caveat is that what counts as boring shifts over time and from team to team.
Dissent
A vocal minority held that "boring" is a vague proxy. They said it works as a slogan to end discussion and defend familiar technology that fits badly. Teams should justify choices against their requirements instead. Others noted that in research or at startups, betting on new technology is sometimes the point.