Feature toggles: types, lifetime and clean-up

What it is

A feature toggle is a conditional in the code whose value is decided by configuration at runtime rather than at build time. The cited article distinguishes release toggles (hide unfinished work), experiment toggles (compare variants), ops toggles (degrade a feature under load) and permission toggles (per-user access), and notes that they differ in how long they live and how dynamic their decisions are.

Why it matters

Toggles make trunk-based development and gradual rollouts possible. They also multiply the number of configurations the system can be in; untested combinations are where surprises live.

How to apply

• Keep the toggle decision in one place (a toggle router) and inject the result; avoid scattering if flag throughout the code.
• Record for every toggle: type, owner, creation date, planned removal date.
• Test both sides of release toggles in the pipeline until the toggle is removed.
• Remove release toggles as soon as the feature is fully rolled out; treat overdue toggles as debt with an interest rate.

Pitfalls

Long-lived release toggles become permanent forks of behaviour. Toggle state spread across environments makes incidents hard to reproduce. Ops and permission toggles are legitimate long-term configuration and should be designed as such rather than left as ad hoc flags.