A platform has accumulated hundreds of feature flags and nobody knows which are safe to remove. What went wrong, and what practice prevents it?

What went wrong

Flags were created with no lifecycle. Each was added for a rollout, the rollout completed, and removing the flag was nobody's task — because the flag is invisible once it is fully on, and removing it is unpaid work with a small risk attached.

The costs compound quietly:

• Combinatorial complexity. N flags means 2ⁿ possible configurations, of which a handful are tested. The configuration a user actually experiences may never have been exercised.
• Dead code paths that nobody dares remove because a flag might still switch them on.
• Testing burden, since correctness in principle requires testing combinations.
• Incidents from unexpected interactions between flags that were each fine alone.
• Cognitive load — reading code means holding several conditional paths in mind.

The practice that prevents it

1. Classify flags by intended lifetime at creation: - Release flags — temporary, removed after rollout. The majority, and the source of the debt. - Operational flags — kill switches and degradation controls. Long-lived by design. - Permission or entitlement flags — permanent, and arguably not flags at all but configuration. - Experiment flags — removed when the experiment concludes.

2. An expiry on every release flag, with an owner. Past expiry it appears in the owning team's backlog automatically, or fails a build.

3. Removal as part of the rollout definition. A rollout is not complete until the flag is removed — the same rule that makes decommissioning work in migrations.

4. Automated detection of flags fully on or fully off for an extended period, proposed for removal with evidence.

5. A cap per service, forcing a trade when a new one is added.

The distinction that matters most

Operational flags are infrastructure and should stay; release flags are debt and should go. Conflating them means either removing kill switches you need, or keeping hundreds of rollout flags forever.

Kill switches, degradation controls and circuit-breaker overrides are genuinely valuable long-lived capabilities — and their value depends on being exercised, so they need periodic testing rather than removal.