“Choose Boring Technology” is a widely circulated software engineering essay arguing that teams should spend their limited capacity for novelty carefully, defaulting to well-understood tools for most of a system.
Key takeaways
- “Choose Boring Technology” is an essay from the mid-2010s that argues engineering teams should deliberately limit how many unfamiliar technologies they adopt at once.
- Its central device is the idea of a small, fixed budget of “innovation tokens” that a team can spend on unusual choices before the operational burden becomes unmanageable.
- The word “boring” in the essay refers to technology whose failure modes are well documented and widely understood, not to technology that is old or unfashionable.
- The argument is about opportunity cost: every novel component consumes attention that could otherwise go to the problem the business actually needs solved.
- The essay is regularly rediscovered and debated on developer forums, where readers disagree about whether it encourages useful discipline or discourages worthwhile experimentation.
What is the “choose boring technology” argument?
The essay makes a resource-allocation argument rather than a technical one. It proposes that any team has a finite capacity to absorb the unknown, and that adopting a new database, language, queue or deployment model each consumes part of that capacity. The suggestion is to treat this capacity as a budget — often described as a small number of “innovation tokens” — and to spend it only where novelty delivers something the team genuinely cannot get otherwise.
The corollary is that most of a system should be built from components whose behaviour under load, under failure and under maintenance is already familiar. “Boring” is used in a specific sense: a boring technology is one whose sharp edges have been found by other people and written down. A technology can be recent and still be relatively boring if its failure modes are well documented; conversely a long-established tool used in an unusual way can behave like an unknown quantity.
A second thread in the argument concerns operational surface area. Each additional distinct technology in a stack adds monitoring, backup, upgrade, security-patching and on-call knowledge requirements. These costs are not visible at the moment of adoption, when the novel tool is being evaluated on features, but they accumulate over the life of the system. The essay frames the decision as a comparison between the capability gained and the long tail of maintenance obligations incurred.
Why is it being discussed again now?
The immediate reason is that the essay resurfaced on an aggregator, where it attracted a moderate volume of votes and a discussion thread. Older technical essays frequently reappear on such sites years after publication, either because someone links to them in another argument or because they are submitted afresh. There is no indication of a new event, publication or announcement attached to this particular resurfacing; the signal is a piece of long-standing writing circulating again.
That pattern is itself part of why the piece endures. The trade-off it describes — familiarity against capability — recurs whenever a new category of tooling becomes popular, and readers reach for a shared vocabulary to argue about it. The essay’s phrasing has become that vocabulary for a portion of the profession, which means it tends to be cited in periods when adoption pressure is high.
What background does a newcomer need?
The essay emerged from a broader industry conversation about the costs of fast-moving stacks. Over the preceding years, the number of viable databases, message brokers, front-end frameworks and deployment platforms had grown substantially, and choosing among them had become a recurring task rather than an occasional one. Teams that adopted many of these at once often found that the aggregate operational load, rather than any single choice, was what slowed them down.
Related ideas circulate under different names. Discussions of “resume-driven development” describe the incentive for individual engineers to adopt tools that improve their marketability rather than the system. Arguments about “accidental complexity” distinguish difficulty inherent to a problem from difficulty introduced by the solution. The boring-technology framing sits alongside these as a practical heuristic rather than a formal method: it offers a way to have the conversation, not a rule that produces an answer.
It is worth noting what the essay does not claim. It does not argue that new technology is bad, nor that teams should never migrate. The token metaphor explicitly allows for spending — the point is that the spending should be deliberate, concentrated where it matters, and understood as consuming a shared resource.
Who does this actually affect?
The people most directly affected are those making architectural decisions in small and medium teams, where the ratio of systems to engineers is high and there is little slack to absorb an unfamiliar failure. In such teams, a single poorly understood component can occupy a disproportionate share of on-call attention.
Larger organisations face a different version of the problem. They may have the staff to operate specialised systems, but they also carry the cost of inconsistency across teams: ten teams each choosing a different queue produces ten sets of runbooks. The essay’s logic is often invoked internally to justify platform standardisation, sometimes to the irritation of teams whose needs genuinely differ.
Individual engineers are affected through career incentives. Working primarily with well-understood tools can be professionally comfortable but may feel limiting to those who want exposure to newer systems. This tension between organisational interest and individual development is one of the more honest difficulties in applying the argument, and it is rarely resolved cleanly.
Newer engineers are affected in another way: joining a system built from familiar components generally means shorter onboarding and more available documentation, while a highly novel stack may offer less external help when something breaks.
Where do informed people disagree?
The most common objection is that “boring” is not an objective property. What is unremarkable to one team is unfamiliar to another, so the advice can be read as “prefer what you already know” — which risks entrenching whatever choices a team happened to make first. Critics argue this can calcify a stack and make necessary migrations harder over time.
A second disagreement concerns the token metaphor itself. Some readers find it a useful conversational device; others consider it too coarse, since not all novel choices carry comparable risk. Replacing a build tool and replacing a primary datastore both count as one token under a naive reading, despite very different blast radii.
There is also a debate about who benefits. Established organisations arguably have more to lose from operational surprise, while smaller or newer efforts may need an unusual technical capability to be viable at all. Some practitioners argue the advice is calibrated for the former and applied too broadly to the latter.
Finally, some object to the framing on cultural grounds, arguing that an emphasis on conservatism can be used to shut down legitimate proposals without engaging with their merits. Defenders respond that the essay asks for justification, not refusal.
What are the practical implications?
In practice, the argument translates into a handful of habits rather than a checklist. Teams that apply it tend to ask what specific capability a novel component provides that the existing stack cannot, and whether that capability is on the critical path for the product. They tend to count the total number of distinct technologies in operation and treat growth in that number as a cost requiring justification.
It also implies asking about the exit. If a chosen technology does not work out, what does removal involve, and how much of the system would need to change? Components that are easy to replace carry less risk than those that shape the data model or the deployment topology, which is one reason the depth of a dependency matters as much as its novelty.
A further implication concerns documentation and staffing. A technology with a large body of public writing about its failure modes is cheaper to operate than one where the team must discover those modes itself, regardless of how long either has existed.
What should readers watch next?
The clearest thing to watch is whether the vocabulary continues to be applied to newer categories of tooling, where adoption pressure is strong and operational experience is comparatively thin. Arguments of this shape tend to be tested hardest when a technology is both genuinely capable and genuinely unfamiliar.
Also worth watching is whether counter-framings gain traction — attempts to describe when spending on novelty is correct, rather than only when it is not. The essay is frequently cited in one direction; a more symmetrical vocabulary would change how the discussions run. Whether either happens is not currently known.
Frequently asked questions
What does “innovation tokens” mean?
It is a metaphor for a team’s limited capacity to absorb unfamiliar technology. The idea is that a team can afford only a small number of unusual technical choices at once, because each one consumes attention for learning, monitoring and incident response. Spending a token means deliberately accepting that cost in exchange for a capability the familiar options cannot provide.
Does “boring” mean old technology?
No. In the essay’s usage, boring refers to technology whose behaviour and failure modes are well understood and documented, not to technology that is old or unfashionable. A relatively recent tool with extensive public operational experience behind it can qualify, while an old tool used in an unusual configuration can behave like an unknown quantity for the team operating it.
Is this advice against trying new tools?
It is not framed that way. The argument allows for adopting novel technology but asks that the choice be deliberate, limited in number, and justified by a capability the existing stack cannot supply. The objection is to accumulating several unfamiliar components at once, where the combined operational load becomes difficult to carry alongside the actual product work.
How many innovation tokens should a team have?
The essay offers a small number as an illustration rather than a measurement, and there is no empirical basis for any specific figure. The point of the metaphor is that the budget is small and shared, not that it has a precise value. Teams that use the idea generally treat the number as a prompt for discussion rather than a limit to be enforced.
What are the main criticisms of this argument?
The most frequent criticism is that “boring” is relative to a team’s existing knowledge, so the advice can amount to preferring the status quo and may entrench early choices. Others argue the token metaphor treats unequal risks as equivalent, since replacing a build tool and replacing a primary datastore differ greatly in consequence despite counting the same.
How does this apply to a small startup?
Views differ. One reading is that small teams have the least capacity to absorb operational surprise and should therefore be most conservative. Another is that a small organisation may need an unusual technical capability to be viable, making a novel choice the correct one. The essay’s logic does not settle this; it mainly asks that the trade-off be made explicitly rather than by default.
Sources and further reading
- The original essay itself, widely available online, which sets out the innovation-token framing in the author’s own terms.
- Hacker News discussion threads, where the piece has been submitted and debated on multiple occasions, offering a range of practitioner reactions.
- General software engineering literature on accidental versus essential complexity, which provides the conceptual background to the argument.
- Published engineering blogs from technology organisations describing platform standardisation decisions and their operational rationale.
Surfaced from the hackernews signal “resurfaced software engineering essay”. AI-assisted draft, editorially reviewed.
