Choosing Boring Technology

Boring technology is not outdated technology. It is technology whose capabilities and failure modes are widely understood: relational databases, mainstream languages, plain queues, well-worn frameworks. Dan McKinley's essay on innovation tokens put the idea concisely: every team has a limited ability to absorb novelty, so spend it where it counts.

Why boring wins

New tools may be better on a benchmark, but your system lives in production, not in a benchmark. What matters operationally is:

• Known failure modes. With mature software, someone has already hit your problem and written about it.
• Hiring and onboarding. More engineers know PostgreSQL than the latest distributed ledger database.
• Tooling and ecosystem. Monitoring, backups, drivers and libraries exist and work.
• Stability. Upgrades are predictable and projects rarely vanish.

With novel tools the unknowns are unknown. You discover them at 3 a.m., and there is nobody to ask.

The innovation token model

Imagine you hold about three innovation tokens. Each unfamiliar technology you adopt in the critical path spends one. A new language, a new primary datastore and a new deployment platform together consume everything, and none of them is the product your customers pay for.

Spend tokens where a technology gives a real competitive advantage tied to your business. A company whose product is real-time collaborative editing might reasonably invest in specialised synchronisation technology. It should still run billing on a boring database.

A decision framework

Before adopting something new, ask these questions and write down the answers:

| Question | Why it matters | |---|---| | What specific problem does the existing stack fail to solve? | Rules out novelty for its own sake | | Have we measured that failure, or are we predicting it? | Avoids premature substitution | | Who will be on call for it? | Surfaces operational ownership | | What is the exit path if it fails? | Tests reversibility | | How many people already know it well? | Quantifies the knowledge risk | | Does it replace something, or add to the stack? | Prevents unbounded sprawl |

The last question matters more than it seems. Technology tends to accumulate. If adopting a new queue does not retire the old one, you now operate both.

Total cost of ownership

The visible cost of a tool is licence or compute. The hidden costs dominate: learning curve, custom operational runbooks, security patching, debugging obscure behavior, and migrating away later. A common pattern is a team choosing a specialised database because it is ten times faster for one query pattern, then discovering it lacks transactions, tooling for backups or support for the reporting queries the business needs.

A short calculation helps. If a boring solution takes 30 percent more infrastructure, but saves a quarter of an engineer's time every month in operations, the boring solution is usually cheaper.

How to try new things safely

Boring does not mean frozen. Teams still need to learn. Do it deliberately:

1. Run an experiment on a non-critical workload, such as an internal tool or a batch job.
2. Timebox it and define success criteria upfront.
3. Document what you learned, including what hurt.
4. Promote or retire. Either adopt it with ownership and runbooks, or remove it completely.

This keeps learning separate from risk on the revenue path.

When boring is wrong

If measured requirements exceed what mainstream tools deliver, such as sustained million-event-per-second ingestion or sub-millisecond latency, specialised tools are justified. Also, a technology that has been stable but is going unmaintained is no longer boring in the useful sense. The test is whether you can predict how it behaves under stress and who can fix it.

Key takeaways

• Boring means well understood, with known failure modes and a deep talent pool.
• Treat novelty as a limited budget and spend it only on what differentiates your business.
• Ask what problem is unsolved, who is on call, and what the exit path is before adopting anything.
• Count operational and hiring cost, not just performance numbers.
• Explore new tools in contained experiments, then adopt or retire them explicitly.