Every flag gets a removal deadline when it is created
Attaching an expiry to a flag at creation time converts removal from an unowned chore into a scheduled decision, which is the difference between a flag system that shrinks and one that only grows.
Do this firstDeploy dark; release with a flag
The same shape as a quarantined test with a deadline, applied to the thing that bought you reversibility in the first place.
This control exists because the control it depends on has a bill attached. Deploying dark behind a flag is the cheapest reversibility you can buy, and every flag you add is a permanent branch in the state space — one that has to be reasoned about, tested against, and eventually removed by somebody who would rather be doing something else. The measured outcome, when removal is left to willpower, is that it does not happen.
The decoy
A quarterly flag cleanup. It is a campaign rather than a mechanism, it competes with feature work every time it runs, and the measured outcome of exactly such a campaign at a well-resourced organisation was that most of the flags it targeted were still there afterwards.
Evidence
- Feature Toggles: Practitioner Practices and a Case Study — IIIFlags accumulate as a maintenance liability even at a well-resourced organisation with a dedicated removal campaign: toggle count grew from 263 to 1,040 across the releases studied, developers made over 5,044 commits introducing or refactoring toggles, and of tracked release toggles only 20% were actually removed while 17% lingered in the source as debt.
Last reviewed 2026-08-19.