Boring technology is a feature

Dan McKinley’s “Choose Boring Technology” is a decade old now, and its central idea — that every team gets a limited number of innovation tokens to spend on unproven tech — has been quoted so often it’s become furniture. Which is a shame, because the argument underneath it is still doing work, and most of the people quoting it stop at the slogan.

Here’s the version I keep coming back to.

Boring means the failure modes are known

When you pick a technology that has been in wide production use for ten or fifteen years, you are not primarily buying its features. You’re buying the enormous, mostly invisible body of knowledge about how it breaks.

You’re buying the fact that when it falls over at 2 a.m., the error message in your logs has been pasted into a search engine ten thousand times before, and someone has written up exactly what it means. You’re buying the fact that your next hire has probably run it. You’re buying the fact that its sharp edges have names.

New technology doesn’t come with any of that. It’s not that new things break more — sometimes they break less. It’s that when they break, you’re the one who has to figure out why, from first principles, on the clock.

The cost is paid later, and by someone else

This is the part that makes the boring choice hard to defend in the moment. The cost of exciting technology is almost entirely deferred. Adoption is fun: the demo is slick, the docs are fresh, the early wins are real. The bill arrives months later, as operational load, as onboarding friction, as the three-day outage that nobody on the team knows how to debug.

And it’s frequently paid by different people than the ones who made the choice. The engineer who introduced the new datastore has moved on to the next interesting problem; the on-call rotation inherits it.

So when you weigh a new tool against a boring one, weigh it against the bill, not the demo.

When to spend the token anyway

None of this means never. It means: be able to say why.

The good reason to adopt something new is that the boring option is genuinely the bottleneck — and you can name the specific limit you’ve hit, with numbers, not the limit you imagine hitting someday. “We might need to scale” is not a reason. “We’re at 80% of what Postgres can do on the biggest box we can buy, and here’s the graph” is.

A heuristic I like: before adopting a new piece of infrastructure, try to write the postmortem for its first serious outage. What broke? How did you find out? Who knew how to fix it, and how did they know? If you can’t fill in that template with anything but hand-waving, you don’t understand the tool well enough to run it in production yet. That’s fine — go learn it in a side project. Just don’t learn it on the critical path.

Where the excitement belongs

The thing I find most persuasive about the boring-technology argument isn’t the risk management. It’s the reframing of where novelty should live.

The interesting part of the work is supposed to be the product — the problem you’re solving for someone, the thing that didn’t exist before. The stack is the means. Spending your novelty budget on the stack is spending it on the part of the job nobody outside the team will ever see.

Pick the boring database. Pick the boring queue. Pick the monolith until it hurts. Then take all the attention that saves you and point it at something that matters.