3 ms·

Yes, I've seen not-so-big product with 100s of feature flags. It's impossible to test for. Just have to hope for the best. No 1 can keep track of them or know w

• dboreham 4y ago
  They should be removed after the feature is deployed and stable. Some folks have a CI task that checks for stale FF and alerts.
  • re-thc 4y ago
    Should is the headline of every incident report :)
• dgb23 4y ago
  There are two similar things that can easily be conflated as they have some overlap, or can at least be used interchangeably in some cases. For one we have feature flags, which should be used to disable features for certain environments, possibly AB testing and so on. You use those to reduce risk and friction in an ad-hoc fashion. They are meant to be simple booleans in code and short lived. Then we have feature scope, registration, authorization etc. which can be more wide reaching. They should be part of the data model and treated like everything else that is data driven. When we conflate the two, we get into trouble like you describe.
  • carlmr 4y ago
    >They are meant to be simple booleans in code and short lived. Simple? One "simple" boolean often doubles the number of code paths. 10 simple booleans can easily 1024x the number of code paths. Short lived? There's nothing as permanent as a temporary measure.