Mutable State

State that changes over time, the values a system remembers between operations. Out of the Tar Pit identifies it as the single largest source of accidental complexity: once behavior depends on accumulated history, the number of states to reason about explodes, and the same input can produce different results depending on what happened before.

Why it Matters

Stateful code cannot be understood in isolation; you must know how the system got here. State multiplies the cases to test and reason about, n bits of state mean 2^n possible states, and it is the root of most "works sometimes" bugs. Minimizing and isolating state is therefore one of the highest-leverage ways to cut complexity.

Signals

• Behavior that depends on the order of previous operations.
• "It only happens after you do X and then Y."
• Bugs that vanish on restart; tests that pass alone but fail when run together.

Benefits

Less state means fewer reachable states, local reasoning, easier testing, and far fewer history-dependent bugs.

Risks

Scattering mutable state throughout the system instead of isolating it; storing data that could be derived, creating extra state that must be kept consistent; mistaking accidental state (caches, performance copies) for essential.

Tensions

Some state is essential, the input the user genuinely provides, and performance sometimes demands accidental state such as caches and indexes. The goal is not zero state but the minimum essential state, with accidental state isolated.

Examples

A function whose result changes between calls with identical arguments because of a hidden mutable field; choosing to recompute a value from its source rather than store and update a separate copy.