The Strategic Balance Between Boring Technology and Innovative Practices

The software development community has long debated the merits of adopting cutting-edge technologies versus sticking with proven, reliable solutions. The famous essay 'Choose Boring Technology' articulates a compelling case for conservatism in technology selection, but it also reveals an important asymmetry: while we should be conservative about the software we use, we can be more freely innovative in how we use it.

The Hidden Costs of Innovation

When we adopt innovative technology, we face two fundamental problems that persist long after the initial excitement fades. First, there are too many 'unknown unknowns' in new technology. With established technologies, the pitfalls are already well-known, documented, and often solved through community experience. Second, shiny new tech carries a maintenance burden that persists long after everybody has gotten bored with it.

These problems tie back to a crucial insight: the main cost of technology is maintenance. Even if something is easy to build with, it might not be as easy to keep running. We cannot 'abandon' mission-critical technology. Consider a team that builds a new service on Julia, only to decide two years later it was the wrong choice. They're stuck with either the expensive process of migrating all their data to Postgres and code to Java, or the expensive process of keeping it running anyway. Either way, the company needs to spend resources keeping engineers trained on the tech instead of other useful things.

The Asymmetry of Technology vs. Practices

Now contrast this with innovative practices. Say at the same time as adopting Julia, we also decided to start practicing test && commit || revert (TCR). After two years, we get sick of that, too. To deal with this, we can simply... not do TCR anymore. There is no 'legacy practice' we need to support, no maintenance burden to dropping a process.

This reveals a fundamental asymmetry: it is much easier to adopt and abandon practices than it is to adopt and abandon technology. This means while we should be conservative in the software we use, we can be more freely innovative in how we use it. If we get three innovation tokens for technology, we get like six or seven for practices. And we can trade in our practices to get those tokens back.

The flip side of this is that social processes are less 'stable' than technology and take more work to keep running. This is why 'engineering controls' are considered more effective at reducing accidents than administrative controls.

Material vs. Tools: A Deeper Framework

Pushing this argument further, we can divide technology into two categories: 'material' and 'tools'. Material is anything that needs to run to support the business: our code, our service architecture, our data and database engine, etc. The tools are what we use to make material, but that the material doesn't depend on. Editors, personal bash scripts, etc.

The categories are fuzzy, but it boils down to 'how bad is it for the project to lose this?' In turn, because tools are easier to replace than material, we can afford to be more innovative with them. I suspect we see this in practice, too, that people replace ephemera faster than they replace their databases.

Strategic Implications

This framework suggests a powerful strategy for sustainable software development. Be extremely conservative about your material choices—stick with battle-tested databases, proven programming languages, and well-understood architectures. These decisions will constrain you for years, and the cost of changing them is enormous.

But be much more experimental with your practices and tools. Try out new development methodologies, experiment with different testing approaches, and explore innovative workflows. If they work, great—you've found a competitive advantage. If they don't, you can simply stop doing them without the massive migration costs that come with changing your core technology stack.

This approach also suggests that the most successful teams might be those that combine boring, reliable technology with innovative, adaptive practices. They get the stability and maintainability of proven tech while maintaining the flexibility and competitive edge that comes from constantly refining how they work.

The Human Factor

The asymmetry between technology and practices also reflects human psychology and organizational dynamics. People are more willing to experiment with processes because the perceived risk is lower. A failed practice experiment doesn't threaten the entire business; it's just a learning experience. But a failed technology experiment can feel like a career-limiting move.

This suggests that fostering a culture of innovation might be more about encouraging experimentation with practices rather than technology. It's easier to get buy-in for trying a new development methodology than for rewriting everything in a new programming language.

Looking Forward

The framework of 'boring material, innovative tools and practices' provides a roadmap for sustainable innovation. It acknowledges that while we can't eliminate all risk from software development, we can be strategic about where we take risks and where we play it safe.

As software continues to eat the world, the ability to make these strategic choices becomes increasingly important. The companies that thrive will be those that can balance the stability needed to run reliable services with the innovation needed to stay competitive. And this balance might just come from being boring about what matters most and innovative about everything else.