3 ms·

Feature flags are not a panacea for deployment issues, they can even create many issues. If there is any interaction between features you start getting combina

by carlmr 4y ago

Feature flags are not a panacea for deployment issues, they can even create many issues. If there is any interaction between features you start getting combinatorial explosion of possible code paths, and you all of a sudden get issues that only affect specific customers due to their set of feature flags. Feature flags have intrinsic complexity. Keeping the code harmonized between customers can cause extra effort when you need to redesign pieces of the system to not need alternative code paths. Both of these costs should be weighed against each other.

re-thc 4y ago
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 what are any more. To make matters worse it can be dynamically enabled based on cookies / headers per customer.
- 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.

by carlmr 4y ago

re-thc 4y ago

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 what are any more. To make matters worse it can be dynamically enabled based on cookies / headers per customer.

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.