The Boring Wisdom: Deconstructing "Choose Boring Technology"
Many people look at Dan McKinley's "Choose Boring Technology" philosophy and think he is being anti-progress or even making an appeal to Luddism, but this is a very mistaken interpretation. Actually, I see it as a refined approach to manage risks, optimize our resources, and boost an organization's long-term performance. The secret isn't running away from the new, but consciously choosing what is predictable and stable. After all, who doesn't want peace of mind when pushing a system to production?
Defining "Boring": Predictability and Productive Ignorance
To understand this philosophy, the first step is to change what we understand by "boring". In McKinley's vocabulary, "boring" doesn't mean the tool is bad, uninteresting, or outdated; it means it is very well understood. A boring technology is one where we know its capabilities and, more importantly, we know exactly how it breaks. PostgreSQL, Python, PHP, and cron are "boring" not because they lack power, but because their behavior under stress and their limitations have already been documented and resolved through years of real-world use.
This aligns perfectly with what Kent Beck calls "Productive Ignorance." In a scenario where everything changes all the time, there is no point in pretending we know everything, right? Productive ignorance is accepting that we don't master certain things and deciding to focus our learning where it truly makes a difference. When we choose "boring," we admit that we don't want to burn brain cells learning the latest trendy framework if what we already have solves the business problem masterfully.
I believe predictability is what saves us from unpleasant surprises in software engineering, which is already a complex discipline by nature. New technologies increase this complexity in a dangerous way, bringing in the "unknown unknowns"—problems we never even imagined existed, quite different from the ones we already know how to plan for, like a network partition.
These innovations are full of unforeseen events: we don't know how they will behave when the system grows or what kind of bizarre errors they might cause. On the other hand, a tool considered "boring" has already transformed almost all of its mysteries into known facts through the use of thousands of people. If we run into a problem, the solution is probably a quick search away. This peace of mind takes a huge weight off the team's shoulders and lets us focus on what the customer really needs, instead of hunting down bugs in a tool we don't even fully understand.
The Economics of the "Innovation Token"
To provide context for adopting new technologies, McKinley brings up a metaphor I really like: "innovation tokens." He says that every company has a very limited supply of these tokens—maybe only around three. They represent our capacity to do something truly creative and risky. And like any scarce resource, we must spend these tokens very smartly, as if they were the company's financial capital.
This idea transforms technical choice into a pure strategy decision. Spending an innovation token on something basic, like replacing a database the team already masters with a "modern" one, is an incredibly high risk for something that brings no differentiator to the business. Does the customer gain any advantage if your database is the latest novelty? Probably not. The advantage comes from the product we build on top of it. If we burn our innovation on infrastructure, we run out of ammo to innovate where the customer actually perceives value.
Deep down, leading technology is managing risks. I see the leader's role as allocating this risk budget in the best possible way. Choosing "boring" for the foundation is like investing in stable assets to ensure the company's bedrock is firm. This preserves our innovation tokens for those high-risk, high-reward bets that will truly change the game in the market.
The Real Cost of Technology: Cognitive and Operational Overhead
We tend to choose tools thinking they are the best for that moment, but we end up forgetting the invisible cost. McKinley always reminds us that the price of a technology goes far beyond initial development. There is the cost of keeping everything running and the mental load it generates for everyone.
This overhead appears in the need to create new monitoring strategies, new tests, and team training. Every new thing we put into the tech stack fragments everyone's knowledge and attention. The case of Etsy illustrates this trap well: they hired people who only knew Python and ended up creating an unnecessary layer in the system that took years to be eliminated. It was a rapid optimization that generated a global headache and delayed the company's success.
On the other hand, when we hold back and use what we already know, the benefits appear in the long run. The folks at Etsy built their activity feed with the basics: PHP, MySQL, and Memcached. Even if the initial implementation took work, the solution scaled 20 times over the years without causing trouble. The stability of the stack left engineers free to focus on what was urgent. The lesson to me is clear: the long-term operational cost is almost always more important than the convenience of using something new right now.
Understanding and applying this "Boring Technology" philosophy is the first step toward building robust and scalable systems. But I know this approach usually faces resistance when the pressure for speed and innovation tightens. In the next article, we will see how to balance this apparent contradiction between being stable and being fast in software development.