Why the Best Technical Decision Is Sometimes the Boring One

The Exciting Choice That Cost Six Months

A team needed a message queue. Someone had just been to a conference where Kafka was prominently featured. They chose Kafka. The use case was a moderate-volume notification system — maybe 1,000 events per day, five consumer groups, no replay requirements.

Kafka has a steep operational learning curve. The team spent weeks getting the cluster configuration right, debugging consumer group rebalancing issues, figuring out the correct offset management strategy, and handling the operational complexity of a distributed log in a system that simply needed to send emails when something happened. Three engineers spent the better part of a sprint on infrastructure that Amazon SQS would have handled in an afternoon.

The system eventually worked. It worked considerably later than it needed to, and it cost significantly more to operate than the simpler alternative would have.

The Bias Toward Novel

There's a consistent pull in engineering cultures toward choosing newer, more sophisticated technology over simpler, established alternatives. The pull has multiple sources:

CV-driven development: Engineers are hired partly based on the technologies they know. Choosing interesting technology creates learning opportunities. Choosing boring technology doesn't look as good on a resume.

Conference-driven selection: The technologies discussed at conferences and in technical blogs are disproportionately novel and sophisticated. Postgres doesn't have a conference talk. The latest time-series database optimized for IoT workloads does.

Boredom with the familiar: Experienced engineers who know a technology well stop finding it interesting. A new technology with interesting problems to solve is more engaging.

None of these are illegitimate human motivations. All of them are misaligned with the goal of building reliable software quickly.

What "Boring" Technology Actually Provides

Boring technology — PostgreSQL, Redis, RabbitMQ, nginx, plain HTTP/JSON REST APIs — is boring because it has been used extensively, its failure modes are well-documented, and the answers to almost every operational question are findable with a search.

That property has enormous practical value:

Predictable failure modes: When something goes wrong with boring technology, there's a community of people who have seen the same thing and written about it. The time from incident to resolution is dramatically shorter.

Available expertise: Hiring engineers who know boring technology is easier. Onboarding new engineers to a system using boring technology is faster.

Operational maturity: Monitoring integrations, deployment tooling, and operational playbooks for boring technology are available and maintained. Building the same for novel technology is your problem.

Reduced cognitive load: When your infrastructure is not surprising, your cognitive budget for application-level problems is larger. Novel infrastructure problems consume engineering attention that should go toward product problems.

The Cases Where Novel Technology Is Justified

The calculus shifts when:

• The problem genuinely requires capabilities that established technology doesn't provide. A time-series database for high-throughput sensor data. A graph database for a social network traversal. These are cases where the fit between the problem and the technology is specific enough to justify the operational overhead.
• The team has deep expertise in the novel technology already. The learning curve cost is already paid.
• The scale or performance requirements have been outgrown by the boring alternative, and this has been measured, not assumed.

In the absence of one of these conditions, the boring choice is usually correct.

Dan McKinley's Formulation

Dan McKinley's "Choose Boring Technology" essay (2015) remains the most direct articulation of this principle. His framing: every team has a finite "innovation budget" — the capacity to absorb the unknown costs of novel technology. Spending that budget on infrastructure leaves less for product. Spending it on product is usually where the value is.

The advice is not "never use new technology." It's "be deliberate about where you spend your innovation budget, because it's limited."

The Practical Takeaway

The next time your team is evaluating technology choices, add one item to the evaluation criteria: what is the operational cost of choosing this technology, and does the problem we're solving justify that cost? Document the boring alternative explicitly — not as a strawman, but as the real option. Then compare not just capability but operational overhead, hiring difficulty, and time-to-first-value. That comparison often makes the right choice obvious.