What "boring" actually means

Dan McKinley's "Choose Boring Technology" essay is now a decade old and more relevant than ever. The insight wasn't "don't use new things." It was: novelty is a cost, and you should spend that cost deliberately.

Every new technology in your stack is something your team must understand deeply, debug under pressure, and maintain through version upgrades. That's a budget. Spend it where it buys real differentiation.

The invisible tax of novelty

When a new framework launches, its documentation covers the happy path. Edge cases, production gotchas, and failure modes emerge over years of real-world use. Stack Overflow answers accumulate. Blog posts document the non-obvious parts. The ecosystem matures.

Teams that adopt technology early pay a hidden tax: they're doing that documentation work themselves, on their own time, in production.

What boring technology actually is

• PostgreSQL has been shipping reliable, correct, featureful releases for thirty years. Its edge cases are documented. Its failure modes are understood. Its backup tools are mature.
• Redis has a simple mental model that hasn't changed in a decade.
• Plain HTTP APIs with JSON are debuggable with curl. No client library required.

These aren't limitations. They're compounding advantages.

The exception

Boring technology is not an excuse to avoid solving real problems. If your problem is genuinely novel, if you're operating at a scale or in a domain where standard tools fail, then novelty is justified. The question is whether you've actually hit that wall, or whether you're just bored.