How configurability as deferred decision-making broke a clinical operations system
Configurability as deferred decision-making, learned the expensive way on a clinical operations system that stayed up while being wrong.
The alert fired at a bad hour, as they do. The system wasn't down. That was the problem. It was up and confidently serving wrong answers, which is a lot worse than an outage because nobody comes looking.
Every setting is a decision someone refused to make, handed to a user who has less context than you do. Some of those handoffs are right. Most are a way of avoiding an uncomfortable conversation, and they're paid for later by whoever has to support all the combinations.
WHAT A SETTING REALLY COSTS
A boolean flag doubles the number of systems you support. Two flags give you four. Nobody plans for this, because each flag arrives on its own, attached to a reasonable request, and the cost only appears in aggregate when a bug report says "it doesn't work" and you need six questions to find out which product they're describing.
The support cost is the obvious one. The subtler cost is that configuration is where domain knowledge goes to die. Once behaviour is a setting, the reason behind it stops being written down anywhere, and in two years nobody can tell you why the value is what it is or whether it's safe to change.
WHEN IT IS THE RIGHT CALL
Sometimes the variation is real and permanent: tax rules that genuinely differ by jurisdiction, thresholds a regulator sets, anything a client can be legitimately audited on. Those belong in configuration, ideally with the reason attached and a name that says which law it serves.
The distinction we use is whether the variation is in the world or in the argument. Variation in the world deserves a setting. Variation in the meeting deserves a decision.
The trigger was boring. A referral sat unrouted for eleven days because its owner had left. The system had no way to represent that, so it picked one, and care coordinators spent the next day proving it wrong with exported CSVs.
DECIDING IN PUBLIC
The alternative to a flag is a decision with a name on it. Write down what you chose, who chose it, and what you'd need to see to change it. That's three sentences and it does more for the next team than a settings page ever will.
It also makes the reversal cheap in the way that matters. Nobody's afraid to change a documented decision. Everyone's afraid to change an undocumented default that eleven clients might depend on.
By the time anyone looked, about 9,000 referrals a month had gone through the affected path. Only a slice of it was wrong, and we couldn't tell which slice without a full replay. The replay was the one thing we'd never tested.
WHERE IT GOES WRONG
- Bug reports that can't be reproduced until you've established which of sixty-four variants the reporter is running.
- Config that encodes a decision but not the reason, so nobody dares touch it after the author leaves.
- Shipping a flag to end a design argument, then discovering both branches are now in production.
- A settings page that nobody can explain, where three values are load-bearing and the rest are noise.
Variation in the world gets a setting. Variation in the meeting gets a decision.
WHAT CHANGED AFTERWARDS
Two action items survived: the two that removed a decision. Everything on the list that asked someone to be more careful was quietly dead within a quarter, which is roughly what we expected when we wrote it.