A feature flag is a small thing. One conditional, one switch, a safe way to ship code without showing it to anyone. That is exactly why teams add them so freely, and why, a year later, nobody can say which ones are still doing anything.
Why flags are worth having
Flags separate deploying code from releasing it. You can merge unfinished work behind a switch, turn a feature on for staff first, roll it out to a fraction of users, and switch it off in seconds if something breaks. For teams shipping often, that is a genuine safety mechanism. We use them and would not give them up.
The trouble is that the benefit arrives on day one and the cost arrives slowly.
Where the interest accrues
Every flag is a fork in the code. Two paths exist where one used to, and both need to keep working. With one flag that is trivial. With twenty, the number of possible combinations is enormous, and nobody has tested most of them.
Costs compound in familiar ways:
- Testing. Each live flag multiplies the states your tests should cover. In practice teams test the default and hope.
- Reading the code. A function wrapped in three conditionals about launches that finished long ago is hard to reason about. New engineers cannot tell which branch is real.
- Stale flags. A switch that has been on for everybody for eight months is no longer a switch. It is dead code with a name, and removing it later feels risky because the reason for it is forgotten.
- Incidents. Changing a flag in production is a deployment of sorts, often with less review than code. A flag flipped to fix one thing can break another, and the config change may not show in the usual history.
Not all flags are the same
Much of the confusion comes from treating different things as one. It helps to name the kinds:
Release flags hide unfinished work. They should be short lived. Once the feature is fully launched, the flag has done its job.
Experiment flags split users to compare variants. They end when the experiment concludes.
Operational flags, sometimes called kill switches, let you disable a risky or expensive feature under load. These can legitimately live for years, but they should be few and documented.
Permission flags gate features by plan or customer. These are really product configuration and belong in a proper entitlement system, not in the same pile as temporary toggles.
When these share one mechanism and one naming style, nobody knows which are meant to expire.
Paying it down
The fix is mostly habit, not tooling.
Give every flag an owner and an expected removal date when it is created. Put it in the ticket, in the code comment, or in the flag system if it supports that. A flag without an owner is a future mystery.
Make removal part of the definition of done. A feature is not finished when it ships to everyone; it is finished when the flag and the old path are deleted. Schedule that cleanup as real work, in the same sprint where possible.
Review the list regularly. A short monthly look at which flags have been fully on or fully off for weeks will find most of the dead ones. Some teams add a build warning or a test that fails when a flag outlives its date.
Keep the number of simultaneous flags low enough that someone could explain them all. If that is no longer true, stop adding and start deleting.
The test we use
Before adding a flag, ask: when will this be gone, and who will remove it? If there is no answer, the flag is not a safety measure. It is a loan with no repayment date, and the interest is paid by whoever reads that code next.