← All insights

In defence of boring technology

There is a specific moment in the life of a platform team when a proposal appears that is technically interesting, well-argued, and wrong. It usually involves a new scheduler, a new message bus, or a new database engine.

We are not against new technology. We are against novelty that has not earned its place.

The accounting problem

Every component in a production stack carries three costs:

• Build cost — the work to get it running. This is the only cost that appears in the proposal.
• Operate cost — the ongoing work to keep it healthy, backed up, upgraded and understood.
• Knowledge cost — the work required for someone who has never seen it to become productive in it.

A mature technology has low knowledge cost because the internet is full of answers, hiring is easier, and failure modes are documented. A novel technology shifts all three costs onto whoever is on call in eighteen months.

A test that helps

When a new component is proposed, we ask four questions:

1. What breaks if we do not adopt it? If the answer is “nothing this year”, the decision can wait.
2. Who operates it at 03:00? Name a person, not a team. If nobody can name one, the operation plan is incomplete.
3. How do we leave? What does migration away look like, and how much data is trapped?
4. What did we remove? Adoption should generally displace something. A stack that only grows is a stack that is accumulating interest.

The fourth question is the most useful. Proposals that add without removing are usually proposing to make an existing problem more sophisticated rather than smaller.

When novelty is correct

Novelty pays for itself when it addresses a constraint that cannot be worked around. Genuine examples from our work:

• A workload whose access pattern made a relational database structurally unsuitable, not merely slow.
• A regulatory requirement that no existing tool satisfied at any price.
• A cost profile where the mature option was an order of magnitude more expensive at the required scale.

Note that all three are constraints, not preferences. “It is nicer to work with” is a real consideration, but it is not sufficient on its own.

The best compliment a platform can receive is that nobody talks about it.

A practical habit

Keep a one-page register of every component in the stack, with the date it was adopted, the reason, and the person who proposed it. Review it annually.

Seeing the list laid out tends to make the next adoption decision easier, and occasionally prompts a removal that saves a great deal of money.