Configurability as deferred decision-making, added late
Retrofitting configurability as deferred decision-making onto a student records platform that wasn't allowed to stop.
Greenfield advice is easy to write and not much use. This is the same idea applied to a system already carrying production load that isn't allowed to stop, with the compromises left in view.
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 code wasn't the hard part. Convincing registrars that a second reader wouldn't cause a withdrawal was backdated after the census had been filed was, because the last project that promised that did exactly that.
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.
We ran both paths against live traffic for three weeks and compared every enrolment record. The mismatch rate started at four percent, all of it the old system's undocumented rounding.
WHERE IT GOES WRONG
- 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.
- Bug reports that can't be reproduced until you've established which of sixty-four variants the reporter is running.
Variation in the world gets a setting. Variation in the meeting gets a decision.
WHAT THE MIGRATION COST
Eleven weeks, one reverted step, nothing customer-visible. The reverted step was the one where we changed two things at once. We keep relearning that and we keep writing it down.