Feature toggles: types, lifespan and cleanup

What it is

A feature toggle (also called a feature flag) is a condition in the code whose value comes from configuration at runtime, not from the build. The cited article distinguishes four categories by lifespan and dynamism: release toggles hide unfinished work on the main branch (short-lived, static); experiment toggles split users into variants (hours to weeks, decided per request); ops toggles throttle or disable functionality under load (switched by hand, usually short-lived, with some kept as permanent kill switches); permissioning toggles unlock functionality for specific user groups (permanent, per user). The article recommends consolidating the decision in a "toggle router" instead of scattering if flag throughout the code.

Why it matters

Toggles enable trunk-based development, staged rollouts and quick rollback without a new deployment. But they multiply the states the system can be in: ten independent toggles give 1024 combinations, of which the tests cover only a few. Forgotten release toggles turn into permanent branches that nobody understands anymore.

How to apply

• Record the following for each toggle when you create it: category, purpose, owner, creation date, planned removal date. Release toggles get an expiry date shortly after the full rollout.
• Keep the decision logic in one place: the code asks "is feature X active in this context?", not "what value is in the configuration?". The answer is passed in as a dependency so that tests can force both sides.
• Test both sides of a release toggle in the pipeline until the toggle is removed: at least the default path and the path with all toggles in their target state.
• Make toggle states visible per environment (a page or an endpoint that lists all toggles with their value and origin) and log changes.
• Plan removal as a task of its own: remove the condition, delete the dead branch, adjust the tests, clean up the configuration. Overdue toggles appear in the backlog like other technical debt.
• Design ops and permissioning toggles that are meant to stay as deliberate configuration: documented, with a default value, with access protection.

Pitfalls

A toggle that changes data formats cannot simply be switched back once data has been written in the new format; this requires expand and contract. Toggle states maintained in several systems make failures impossible to reproduce. Toggles queried by a name string silently return the default value if there is a typo. An experiment toggle that stays after the experiment keeps both variants alive.