The famous article 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, and 2 years later decides it was the wrong choice. We're stuck with either the (expensive) process of migrating all our data to Postgres 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.

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 (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 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 than administrative controls.)

Choose Boring Material and Innovative Tools

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 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

It's in a week! You can submit your April Cools in the google form or, if you want to be all cool and techie, as a github PR.