skip to content
Site header image reelikklemind

The Wisdom of Boring

Why Choosing Familiar Technology Might Be the Bravest Innovation of All

🌲 Evergreen ✏️ Writings 👔 Business

The Wisdom of Boring: Why Choosing Familiar Technology Might Be the Bravest Innovation of All

In an industry obsessed with the latest frameworks, cutting-edge databases, and revolutionary programming languages, Dan McKinley's "Choose Boring Technology" presentation and essay feel almost heretical. Yet, after absorbing his arguments, I'm convinced that his approach might just be the most truly innovative thinking in software development today.


McKinley's core metaphor of "innovation tokens" is brilliant: companies get about three, and they should spend them on what actually matters (solving their core business problems), not on reinventing infrastructure. If your company's mission is to "reshape global commerce" or "revolutionize payments," why waste your limited innovation capacity on debating whether to use the newest NoSQL database?


What resonates most deeply is McKinley's distinction between "boring" and "bad." Boring technology like MySQL, Postgres, Python, etc. isn't exciting, but its failure modes are well-documented and understood.

In contrast, shiny new technology comes with what McKinley calls "unknown unknowns": problems you don't even know to look for. When your production system crashes at 3 AM because of some edge case nobody anticipated, that "exciting" technology suddenly feels like a liability.


The best argument against the "best tool for the job" mentality is its myopic view of costs. Yes, Redis might be technically superior for caching, but what about the operational overhead? The cognitive load on your team? The monitoring, deployment, and maintenance costs? McKinley rightly points out that long-term operational costs almost always dwarf short-term development conveniences.

However, I'd add a nuance: this philosophy shouldn't become dogma. The key isn't to never adopt new technology, but to be deliberate and conservative about it. McKinley's framework for evaluating new tools: first asking if you can solve the problem with existing technology, documenting current stack limitations, and planning migrations, is exactly the right approach.


In a time where developers often measure their worth by the number of technologies they've mastered, McKinley's message is countercultural: real freedom comes from focusing on your product, not your tools. The bravest innovation might be choosing to be boring.


Sources:



Crepi il lupo! 🐺