Three myths about state management

The version of this that works is simpler than the version most people imagine. A few things about state management that get repeated more often than they get checked.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. If two people in the business would answer this differently, that gap is the actual problem.

“It only matters for big sites”

Most apps need far less shared state than they end up with. Small and consistent beats large and occasional here. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

“We can deal with it after launch”

Sometimes true, usually expensive. Where this goes wrong is almost never a lack of knowledge.

“Our platform handles it”

Every duplicated piece of state is a future bug. None of that requires a large budget, only a decision and someone to own it. Write the reasoning down alongside the decision, because the reasoning is what changes first.

In practice

Most development decisions are really maintenance decisions wearing a different hat. Three things worth confirming about state management before you move on:

• Someone can say what the current setup is without going to look
• Every duplicated piece of state is a future bug — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.