Choose Boring Technology and Innovative Practices
Summary
The article argues that teams should choose boring, well-understood technology for reliability, while being free to innovate in development practices like TCR (test && commit || revert), which are easier to adopt and abandon without long-term maintenance burden.
<p class="empty-line" style="height:16px; margin:0px !important;"></p>
<p>The famous article <a href="https://mcfunley.com/choose-boring-technology" target="_blank">Choose Boring Technology</a> lists two problems with using innovative technology:</p>
<ol>
<li>There are too many "unknown unknowns" in a new technology, whereas in boring technology the pitfalls are already well-known.</li>
<li>Shiny tech has a maintenance burden that persist long after everybody has gotten bored with it. </li>
</ol>
<p>Both of these tie back to the idea that 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. Say my team builds a new service on <a href="https://julialang.org/" target="_blank">Julia</a>, and 2 years later decides it was the wrong choice. We're stuck with either the (expensive) process of migrating all our <del>data to Postgres</del> 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, like how to mine crypto in their heads. </p>
<p>Tech is slow to change. Not as slow to change as, say, a bridge, but still pretty slow.</p>
<p>Now say at the same time as Julia, we also decided to start practicing <a href="https://medium.com/@kentbeck_7670/test-commit-revert-870bbd756864" target="_blank">test && commit || revert</a> (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. It is much easier to adopt and abandon practices than it is to adopt and abandon technology.</p>
<p>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 <a href="https://mcfunley.com/choose-boring-technology#embrace-boredom" target="_blank">three innovation tokens</a> for technology, we get like six or seven for practices. And we can trade in our practices to get those tokens back. </p>
<p>(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 <a href="https://hillelwayne.com/post/hoc/" target="_blank">more effective as reducing accidents</a> than administrative controls.) </p>
<h3>Choose Boring Material and Innovative Tools</h3>
<p>Pushing this argument further, we can divide technology into two categories: "material" and "tools".<sup id="fnref:tools"><a class="footnote-ref" href="#fn:tools">1</a></sup> Material is anything that needs to run to support the business: our code, our service architecture, our data <em>and</em> 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?" </p>
<p>In turn, because tools are easier to replace than material, we can afford to be more innovative with it. I suspect we see this in practice, too, that people replace ephemera faster than they replace their databases.</p>
<p>(This is a short one because I severely overestimated how much I could write about this.)</p>
<hr />
<h2><a href="https://www.aprilcools.club/" target="_blank">April Cools</a></h2>
<p>It's in a week! You can submit your April Cools in the <a href="https://docs.google.com/forms/d/e/1FAIpQLSc6Yt_ZCA_S6EOt-VVtla-uObnzPlSg9x_VOLgiNGN_-AY-kQ/viewform" target="_blank">google form</a> or, if you want to be all cool and techie, as a <a href="https://github.com/april-cools/april-cools.github.io/blob/main/_data/projects.yml" target="_blank">github PR</a>.</p>
<div class="footnote">
<hr />
<ol>
<li id="fn:tools">
<p>This is different from how we call all software "tools". <a class="footnote-backref" href="#fnref:tools" title="Jump back to footnote 1 in the text">↩</a></p>
</li>
</ol>
</div>
View Cached Full Text
Cached at: 05/16/26, 03:39 AM
# Choose Boring Technology and Innovative Practices
Source: [https://buttondown.com/hillelwayne/archive/choose-boring-technology-and-innovative-practices](https://buttondown.com/hillelwayne/archive/choose-boring-technology-and-innovative-practices)
The famous article[Choose Boring Technology](https://mcfunley.com/choose-boring-technology)lists two problems with using innovative technology:
1. There are too many "unknown unknowns" in a new technology, whereas in boring technology the pitfalls are already well\-known\.
2. Shiny tech has a maintenance burden that persist long after everybody has gotten bored with it\.
Both of these tie back to the idea that 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\. Say my team builds a new service on[Julia](https://julialang.org/), and 2 years later decides it was the wrong choice\. We're stuck with either the \(expensive\) process of migrating all ourdata to Postgrescode 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, like how to mine crypto in their heads\.
Tech is slow to change\. Not as slow to change as, say, a bridge, but still pretty slow\.
Now say at the same time as Julia, we also decided to start practicing[test && commit \|\| revert](https://medium.com/@kentbeck_7670/test-commit-revert-870bbd756864)\(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\. 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](https://mcfunley.com/choose-boring-technology#embrace-boredom)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 as reducing accidents](https://hillelwayne.com/post/hoc/)than administrative controls\.\)
### Choose Boring Material and Innovative Tools
Pushing this argument further, we can divide technology into two categories: "material" and "tools"\.[1](https://buttondown.com/hillelwayne/archive/choose-boring-technology-and-innovative-practices#fn: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 it\. I suspect we see this in practice, too, that people replace ephemera faster than they replace their databases\.
\(This is a short one because I severely overestimated how much I could write about this\.\)
---
## [April Cools](https://www.aprilcools.club/)
It's in a week\! You can submit your April Cools in the[google form](https://docs.google.com/forms/d/e/1FAIpQLSc6Yt_ZCA_S6EOt-VVtla-uObnzPlSg9x_VOLgiNGN_-AY-kQ/viewform)or, if you want to be all cool and techie, as a[github PR](https://github.com/april-cools/april-cools.github.io/blob/main/_data/projects.yml)\.
Similar Articles
Optimize for change not application performance
The article argues that software teams often over-optimise for micro-performance benchmarks at the expense of developer experience and engineering throughput, which are the true bottlenecks for long-term delivery speed and maintainability.
Quoting Mitchell Hashimoto
Mitchell Hashimoto observes that most technical decision-makers prioritize job security over innovation, leading them to adopt safe, trendy solutions like AI context engines rather than building defensible technology.
I’d choose a boring workflow over a flashy AI idea every time
The author argues that the real opportunity in AI is not flashy apps but automating boring, repetitive workflows in specific industries, advising founders to start by manually doing the work and building small, targeted solutions.
AI benchmarks matter less than whether models can handle boring real-world responsibility
The article argues that AI benchmarks and flashy demos are overemphasized; the real test for AI trustworthiness is how models handle boring real-world responsibilities like following instructions, admitting uncertainty, handling edge cases, and being auditable.
Use Boring Languages with LLMs
An opinion piece arguing that LLMs perform better with boring, consistent languages and ecosystems (like Ruby on Rails) because the training corpus has lower variance, leading to more reliable agentic output, while fragmented ecosystems (like JavaScript) produce poor results.