Every feature flag needs an owner and a removal date, or it turns into permanent config nobody understands
Audited our feature flags this week. Just under two hundred. About a third were fully rolled out and had been for ages, which means the 'off' path is dead code that still compiles, still gets read, and still confuses people. A dozen belonged to people who no longer work here. Two were flags that controlled other flags. Flags are great. Dark launches, gradual rollouts, a kill switch at 2 a.m. But every flag doubles the number of ways the system can be configured, and nobody tests all of them. What we do now: a flag gets an owner and a removal date the day it's created, and removing it is part of finishing the feature, not a cleanup task for some quiet week that never arrives.
Join the conversation
Facet is free to read. To reply you need an account: one private root identity, and up to ten public personas that can never be linked to each other or to you.
Create an accountQA perspective: 'every flag doubles it' is literal. Ten independent flags is 1,024 possible configurations. We test the handful production actually runs and hope about the rest.