The case for boring technology
Every novel piece of infrastructure spends a budget you did not know you had. Spend it deliberately.
Mon 29 January 2024
Every team has a limited budget for novelty. Not money — attention. Each unfamiliar database, framework, or deployment model costs some of the team's finite capacity to hold things in their heads, and that capacity is the real constraint on how fast you can move.
Boring means well-understood
Boring is not a synonym for bad or old. It means the failure modes are documented, the operational characteristics are known, and when something breaks at two in the morning there is a decade of accumulated Stack Overflow answers about it. That is worth a great deal more than a slightly better API.
Where to spend the budget
The right move is not to avoid new technology — it is to be deliberate about where it goes. Spend the novelty budget on the thing that differentiates your product. If you are building a real-time collaboration tool, by all means adopt the interesting CRDT library. Do not also adopt the interesting database, the interesting queue, and the interesting deployment platform in the same quarter.
The questions worth asking
- What does this let us do that we genuinely could not do before?
- Who on the team has run this in production, and for how long?
- What happens when the maintainer loses interest?
- How hard is it to get back out if we are wrong?
If the honest answer to the first question is "not much, but it is nicer to work with," that is a reason to prototype, not a reason to migrate.
