blog

Choosing Boring Technology

Dan McKinley's essay on choosing boring technology is one of the most useful things written about software engineering. The core idea: every team has a limited budget of complexity they can absorb. Spend it wisely.

I have been thinking about this more as I've watched projects fail — not because of technical limitations, but because the team chose interesting technology over well-understood technology, and then paid the tax for that choice for years.

The novelty premium

When you choose a new technology, you pay a premium that older, better-understood tools do not charge:

  • Unknown failure modes. Old software has been broken in every possible way. Its bugs are documented. Its edge cases are mapped. New software surprises you.
  • Smaller talent pool. Hiring becomes harder. Onboarding takes longer. The team's institutional knowledge is fragile.
  • Immature tooling. The debugging tools, profilers, test utilities, and deployment guides that mature ecosystems take for granted don't exist yet.
  • API instability. Things change. Migrations happen. The cost of keeping up is real.

None of this means avoid new technology entirely. It means price it correctly.

What "boring" actually means

Boring technology is not bad technology. It is technology that has been around long enough that:

  1. Its tradeoffs are documented and understood
  2. You can hire people who already know it
  3. Google will return answers to your questions
  4. The error messages make sense
  5. Someone has already solved the problem you're about to have

Postgres is boring. Redis is boring. S3 is boring. These are among the most reliable, well-understood pieces of infrastructure in the industry. They are not boring because they are bad. They are boring because they work, reliably, in well-documented ways.

When new technology is worth it

Sometimes novelty is the point. If the technology you are building requires something that existing tools cannot do, then you have no choice.

The question is always: does this new tool solve a problem that I actually have? Not a problem I might have. Not a problem that makes for a good conference talk. A real, current, measurable problem.

If the answer is yes, pay the novelty premium consciously and budget for the hidden costs. If the answer is no — and it usually is — reach for something boring.

A personal rule

I now ask one question before adopting any new dependency: what is the fallback if this project is abandoned?

For boring technology, the answer is easy: fork it, vendorise it, migrate to the boring alternative. For new technology, this question is much harder to answer — and the difficulty of answering it tells you something.