Five mistakes teams make with state management

There is no clever trick in this one, just a handful of decisions worth making deliberately. These are the ones we run into repeatedly when we audit state management.

Most development decisions are really maintenance decisions wearing a different hat. Doing this properly once is usually cheaper than doing it approximately three times.

Common failure modes

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Most apps need far less shared state than they end up with
• Derive values rather than storing them twice
• Never checking whether the fix actually worked

Every duplicated piece of state is a future bug. The reasoning matters more than the rule, because the rule has exceptions. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Making it stick

What this looks like day to day

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about state management before you move on:

• Someone can say what the current setup is without going to look
• Derive values rather than storing them twice — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.