Boring technology, revisited

The "choose boring technology" argument goes like this: you have a small number of innovation tokens. Spend them on the thing that is genuinely your problem. Everything else should be the option so well-understood that its failure modes are documented by strangers.

It has held up for a decade. It is worth restating because a decade is long enough that people have started applying it wrongly, in a specific and predictable way.

why it works#

Known failure modes. The value of a boring technology is not that it is good. It is that when it breaks at 3 a.m., the error message has been pasted into a public forum by someone who then explained the fix.

A hiring pool that already knows it. Every unusual choice is a thing you must teach every new engineer, forever.

Operational surface you can reason about. Boring things have runbooks, monitoring integrations, backup tooling, and a decade of accumulated operational wisdom.

Someone else finds the bugs. A widely-deployed system has been run at scales you will never reach, by people who reported what broke.

the amendment#

Here is what the original argument does not say, and what a decade has taught: boring is a property of a technology at a moment in time, and it moves in both directions.

Things become boring. Things also stop being boring — a project loses its maintainers, its community fragments, its corporate sponsor reorganises, the ecosystem moves and it does not.

So "choose boring" is not a decision you make once. It is a property you have to re-check, and the failure mode nobody plans for is the technology that was the safe choice in 2019 and is now a liability that everyone forgot to reconsider.

The practical version: once a year, for each load-bearing dependency, ask — is this still boring? Is it still maintained, still hired for, still the thing a new engineer would expect? A "yes" costs a minute. A "no" is the most valuable thing you will learn that quarter.

how to tell whether something is boring now#

Not by age. Some old things are unmaintained; some five-year-old things are completely settled.

The signals that actually matter:

• Multiple independent maintainers, ideally from more than one employer.
• A release in the last six months, and a changelog that shows maintenance rather than churn.
• You can hire for it. Search jobs, not GitHub stars.
• Operational documentation written by users, not just by the vendor.
• A migration path off it, documented by people who took it. A technology nobody has successfully left is a technology you cannot leave.
• Boring failure modes. Can you name what happens when it runs out of memory, loses its network, or gets a corrupt config? If nobody has written that down, it is not boring yet.

where to spend the tokens#

The argument's real content is that innovation tokens are scarce, and the scarcity is not about technology risk. It is about attention.

Every unusual choice consumes attention: to learn it, to operate it, to debug it, to explain it. Attention is the actual constraint on an engineering team, and it is far more limited than the budget.

So spend the tokens where the unusual choice is the product. If your differentiator is a query engine, be adventurous about storage and utterly boring about everything else. If your differentiator is a workflow, use the most conventional stack in existence and put all the attention into the workflow.

The teams that get this wrong are almost never wrong about one big choice. They are wrong about six small ones, each individually defensible, that together consumed all the attention that should have gone into the thing customers pay for.

the counterweight#

Taken too far this becomes an argument for never learning anything, and that is its own failure. A team that made every choice in 2016 and never revisited one is not disciplined, it is stuck — and the technology it chose has probably stopped being boring in the meantime.

The synthesis: be adventurous in one place at a time, deliberately, with a written reason. Be boring everywhere else. Re-check annually.

That is a harder discipline than either "always use the new thing" or "never use the new thing," and it is the only one that survives a decade.