Four feature flags, and how long they live
A classification that is not mine, and the question it leaves open: the date the flag goes away. With no written answer, it becomes part of the product.
This site’s mark is a switch, which obliges me to some rigour on the subject. Martin Fowler sorted feature flags (he writes feature toggles) into four families; the classification is his, and I am not repeating it to improve on it, but because it sets up the question it only touches in passing: how long the flag lives.
- Release flag: it hides unfinished code inside a version already shipped. It must die when the work ends.
- Experiment flag: it sends two populations down two paths to compare. It must die with the measurement, whose length is decided in advance.
- Ops flag: it cuts an expensive feature when the system is under strain. It lives as long as the system.
- Permission flag: it opens a feature to certain accounts. It lives as long as the product, because it is not a flag: it is a business rule.
The order is not decorative: it runs from the most short-lived to the most permanent. The first two must go, the last two are meant to stay. Confusing the halves is the ordinary mistake, and it is always made the same way round: a temporary flag gets treated as settled.
Each flag doubles the number of paths through the code; two of them quadruple it. The cost is not in the condition, three lines, but in what stops being tested, namely the combinations. A release flag forgotten after release leaves behind a path nobody walks, nobody tests, and nobody dares remove because nobody remembers what it was for.
Every flag of the first two families is born with a removal date written in the same place as the code, not in a tracking ticket that gets closed. Past that date it is removed or argued for; there is no third outcome. It is a tiresome constraint, and the only one I have seen hold beyond a quarter.
This piece says nothing about tooling: the services that steer flags remotely, their dashboards, their invoices. They solve the distribution of the setting, not its removal, and removal is the problem. On a system held by one person, a configuration file and a date are enough, and I would struggle to justify more.