Signs it is time to revisit state management

This is one of those topics that looks small until it costs you something. A few signals that state management is due some attention.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. It rarely shows up as a line item, which is exactly why it slips.

The signals

• Nobody can say when it was last reviewed
• The answer depends on who you ask
• Most apps need far less shared state than they end up with
• Derive values rather than storing them twice

The practical version

Every duplicated piece of state is a future bug. This is the sort of thing that compounds, quietly, in both directions. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

In practice

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about state management before you move on:

• Someone can say what the current setup is without going to look
• Most apps need far less shared state than they end up with — 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.