Main idea

Software best practices are often talked about as a stable stock: it would be enough to document them, drop them into a coding assistant's guideline file, and ask it to apply them.

Their history says otherwise. The classic design patterns answered a given software world; the cloud, distributed systems, async, microservices and event-driven architectures brought another one into view, and idempotence, retries, circuit breakers, sagas, observability and distributed resilience had to be invented. None of these practices came out of rereading the previous ones: they were born from real systems, outages, painful migrations, operational constraints and difficult trade-offs.

So inventing a best practice takes more than knowing the old ones. You have to sense why they are no longer enough, which means having been exposed to a field that pushes back — and knowing how to tell the moment when a pattern is an elegant answer from the moment it is just unnecessary complexity.

Why it matters

This separates two capabilities that get confused as soon as a tool can recite the catalogue: applying a practice and producing a new one. An assistant that compares solutions, spots recurrences and documents emerging practices helps with the first; nothing establishes that it covers the second before the field has made the need legible.

It also puts a figure on an invisible cost for a team that no longer faces operations directly: it inherits the existing patterns and loses the mechanism that let it invent others — a loss you only observe at the next technology generation.

Nuances and limits

The field doesn't have to be lived first-hand to instruct: a serious post-mortem, an operational trace, another company's public incident all carry part of the resistance. What they transmit for certain is the pattern already found; their capacity to bring out the next one remains to be demonstrated.

And not all resistance produces a practice: plenty of incidents leave nothing but a local fix, because nobody took the time to draw a rule from them.

Open questions

• What is it, in an outage, that makes it generate a reusable practice rather than a fix forgotten the following month?