Boring is a feature

Most software does not fail because it lacks innovation. It fails because it accumulates complexity faster than it accumulates understanding.

The seduction of novelty

There is a recurring pattern in engineering teams. A new project begins, constraints are loose, and the team has real freedom. Almost immediately, someone proposes using the newest framework, the most recent database engine, the language the community has been excited about for the past six months.

The reasoning always sounds sensible: better performance, improved developer experience, more modern abstractions. What rarely gets said out loud is that these choices carry a hidden cost — one that will not be paid by the people making the decision, but by whoever maintains the system two or three years from now.

The invoice arrives late

Novelty is expensive, but the bill comes later.

When a system is built on unfamiliar or immature technology, the cost is deferred. In the short term, everything feels good. The team is energized. Velocity is high. The system does what it was designed to do.

The bill arrives when something breaks at 3am and the runbook does not cover this particular version of the dependency. It arrives when the original engineers leave and the new team spends weeks trying to understand a decision that seemed obvious at the time. It arrives when the framework releases a breaking change and a migration that should take a day takes a quarter.

These costs are real, but they are invisible in the planning document. They do not show up in sprint velocity. They accumulate quietly, until they become a ceiling on everything the team can do.

What “boring” actually means

Choosing boring technology is not the same as being conservative, risk-averse, or unambitious. It is about understanding what kind of risk you are accepting.

Boring systems fail in predictable ways. When a Postgres instance runs out of connections, the error is well documented, the fix is well understood, and the community has seen it a thousand times. When your bespoke distributed cache fails under an unusual write pattern, you are debugging in the dark.

Boring technology has better documentation. It has Stack Overflow answers from eight years ago that still apply. It has textbooks written about its failure modes. It has engineers available to hire who do not need a six-month training period before they become productive.

Most importantly, boring technology allows a team to focus on the actual problem it is trying to solve, rather than on the infrastructure it chose to solve it with. That is the point. Competitive advantage should come from the domain logic, not from the novelty of the storage layer.

Spending innovation tokens wisely

Dan McKinley introduced the concept of “innovation tokens” — the idea that any team has a limited budget for unconventional choices. Spend a token on a new database and you have one fewer for the novel data model your product actually requires. Spend a token on an emerging language and you have one fewer for the unusual caching strategy your scale demands.

Used wisely, innovation tokens produce real advantage. Used carelessly, they produce impressive architecture diagrams and slow teams.

The question is never “is this technology interesting?” The question is “is this the right place to spend a token?”

When novelty earns its place

There are legitimate cases for new technology. When a proven option genuinely cannot meet the requirement — not “might not meet it someday” but demonstrably cannot — novelty earns its place.

When the team has deep prior experience with the new technology and the risk is understood rather than assumed, the calculation changes. When the organization has the operational maturity and the capacity to absorb a learning curve, the investment can be justified.

But these cases are rarer than teams assume. Most applications do not have scale requirements that justify a custom distributed system. Most teams do not have the operational depth to run infrastructure they do not yet understand.

In practice

In practice, this means starting with the boring choice and requiring a clear case to deviate from it. It means asking “what happens when this breaks?” before asking “what are the benchmarks?”

It means building systems that the next engineer can understand without reading an internal wiki that no one has updated in eighteen months. It means writing code that the team can still reason about when the original authors are long gone.

Good architecture is not about being impressive. It is about being dependable.

And dependability, most of the time, looks a lot like boring.