State management: the questions we get asked most

Every audit we run turns up some version of this. The questions about state management that come up most often on our calls.

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

Do we need to care about this?

Most apps need far less shared state than they end up with. This is the sort of thing that compounds, quietly, in both directions. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. That sounds obvious written down. It is still the thing most often skipped.

How do we know it is working?

Every duplicated piece of state is a future bug. This is the sort of thing that compounds, quietly, in both directions. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

How to tell if yours is fine

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

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