The feature flag that never got removed

Feature flags solve a real problem. Deploy and release stop being the same event, a change can be turned off without a rollback, and a risky path can be exposed to 1% of traffic first.

Then they accumulate, because adding one is a line of code and removing one is a decision nobody is asked to make.

The cost is combinatorial

Two flags mean four possible configurations. Ten mean 1,024. Three hundred mean a number with ninety digits, and your test suite covers exactly one path through it — whatever the defaults happen to be.

In practice this means:

• The combination in production may never have been run in CI. Flag states differ between environments, and the flags are set outside the code.
• Reproducing a bug requires knowing the flag state, which is not in the stack trace, the logs, or the ticket unless someone made it so.
• Reading the code becomes conditional. A new engineer cannot tell which branch is live, so they read both, and the flag has now cost them twice.

Two kinds, and conflating them is the mistake

Release flags are temporary. They exist to separate deploy from release, and they have a natural end: the feature is fully on, or it is deleted. Their lifetime should be days or weeks.

Configuration is permanent. Per-tenant limits, regional behaviour, plan entitlements, kill switches for expensive subsystems. These are not debt — they are the product, and they should live in a configuration system with an interface that says so.

Most flag sprawl is release flags that were never closed out, sitting in the same list as permanent configuration, which is why nobody can tell which are safe to remove.

What to require when a flag is created

Four fields, enforced by the flag system rather than by good intentions:

1. An owner. A person, not a team alias. Teams do not clean things up.
2. A removal date. Not a hope — a date, on which something happens automatically.
3. The type. Release or configuration. This is the single most useful piece of metadata, because it decides whether the flag has an end.
4. What it does when the system cannot reach the flag service. Every flag needs a default that is safe when evaluation fails, and choosing it at creation is much easier than choosing it during an incident.

Removing them is part of shipping

The flag comes out when the feature is fully rolled out — not in a cleanup sprint, which does not happen, and not in a backlog ticket, which is where flags go to become permanent.

A workable rhythm:

• The pull request that takes a flag to 100% includes the removal ticket, assigned, with a date.
• A weekly report of flags past their removal date, sent to the owner rather than a channel. Named individuals respond; channels do not.
• A hard limit on live release flags. A number the team agrees, past which new flags require removing an old one. Artificial, and it works — the alternative is an unbounded list nobody feels responsible for.

A flag with no removal date is not a flag. It is an untested branch of your codebase with a switch on the outside.

Removing one safely

1. Confirm the state everywhere. Every environment, every tenant, every region. A flag at 100% in production and 0% in staging is not finished.
2. Delete the losing branch and the flag check together, in one change. Leaving the check with a constant is how a flag survives its own removal.
3. Search for the flag name across the whole repository, including tests, configuration, analytics events and dashboards. Analytics that segments on a removed flag reports nothing and nobody notices for months.
4. Remove it from the flag service last, after the code is deployed. The reverse order means a window where the code asks for a flag that no longer exists — which is exactly when you discover what the missing-flag default was.

The one to keep

Kill switches for expensive or fragile subsystems are worth keeping permanently and worth testing deliberately: turn one off in a non-production environment on a schedule and confirm the system degrades the way you think it does.

An untested kill switch is not a safety mechanism. It is a belief about one, and you find out which during the incident it was meant for.

What is a feature flag?

A feature flag is a runtime condition that selects between 2 code paths without a deploy. That is its value — deploy and release stop being the same event — and also its cost, because both paths remain in the codebase and only one of them is exercised by any given run.

A feature flag is therefore debt with an interest rate. The interest is paid by whoever reads the code next.

Which kind of flag is this?

Conflating these 2 is the root of most flag sprawl. Release flags that were never closed out end up sitting in the same list as genuine configuration, and once they are mixed nobody can tell which are safe to remove.

How many can a codebase carry?

It is not a count. It is the number of release flags past their removal date, because those are the ones representing untested combinations nobody intended to keep.

The 4 fields to require at creation: an owner who is a person, a removal date, the type, and the behaviour when the flag service cannot be reached. The last is the one chosen during an incident if it is not chosen at creation, and incidents are a poor time to make it.

Then treat removal as part of shipping — the pull request that takes a feature flag to 100% carries the removal ticket with it. See also our writing on DevOps practice, software engineering generally, and the product engineering decisions behind both.

Removing one without breaking anything

The order matters more than the care taken. Confirm the state in every environment and every tenant, delete the losing branch and the feature flag check together in one change, deploy, and only then remove it from the flag service. Reversing the last 2 steps leaves a window where the code asks for a flag that no longer exists, which is precisely when you discover what the missing-flag default was.

Search the whole repository for the name before you finish — tests, configuration, analytics events and dashboards. Analytics segmented on a removed feature flag reports nothing at all, and nobody notices for months. Trunk-based development treats this cleanup as part of the change rather than a follow-up, which is the only way it reliably happens.