9 ms·

I’m currently reverse engineering a large enterprise app and the feature flag bloat is truly astounding. Imho excessive feature flag complexity is a symptom of

by maxidog 16d ago

I’m currently reverse engineering a large enterprise app and the feature flag bloat is truly astounding. Imho excessive feature flag complexity is a symptom of management who are indecisive and mistrusted by the developers.

Lucasoato 16d ago
This of course depends on the quantity and the depth of these feature flags. It’s ok to hard code few of them, maybe it’s not when it becomes a practice and you have tens of them. I think you would have a much easier life if there was a standardized, well documented, way to define them.
Gigachad 16d ago
You need to be actively deleting them after the feature has gone live
- forgotaccount3 16d ago
  Create story to add feature flag controlling access to the feature. Immediately create story to remove said feature flag controlling access to the feature and review it during backlog refinements.
- chasd00 16d ago
  i could see it getting complex with a lot of flags, inevitable you'll run into a situation where more than one flag is combined. something like enabledFeature = (flag1 || flag2 || flag3) && flag4 then, down the road, you remove flag4. Hopefully the above would result in a compile error but you may be in a language or situation where a missing flag4 is interpreted as boolean false. That could cause all kinds of havoc in logical combinations like that are scattered all over the codebase. Even worse would be REST APIs retrieving flag values because who knows what's happening in that service code? Plus, you'd never know there was an issue until users start reporting missing or extra features showing up unless you have e2e tests for every possible combination of feature flags...
  - lpribis 16d ago
    Surely the commenter means deleting them in the code, not just the management software. Otherwise, what's the point? You need to find every occurrence of flag4 and remove references to it. So that boolean expression would need to have `&& flag4` removed.
    - chasd00 16d ago
      What I’m saying is there may be references you don’t have access to.
not_a_bot_4sho 16d ago
> Imho excessive feature flag complexity is a symptom of management who are indecisive and mistrusted by the developers. In my experience, engineers aren't using them to account for managerial dithering, they're doing it for safe deployments and experiments and rollouts and such. A product with millions of users can easily have a tens or even hundreds of active switches at any moment (I'm assuming a large engineering team behind said product), and that's not necessarily a bad thing. However, as someone else noted here, you absolutely MUST delete and clean up your flags/gates/whatever when you've completed that effort. That part can be tricky because not everyone has the discipline to pay off tech debt. Usually, a flag/gate should not live in code for more than a few months. If it does, it should have robust justification.

by maxidog 16d ago

Lucasoato 16d ago

This of course depends on the quantity and the depth of these feature flags. It’s ok to hard code few of them, maybe it’s not when it becomes a practice and you have tens of them. I think you would have a much easier life if there was a standardized, well documented, way to define them.

Gigachad 16d ago

You need to be actively deleting them after the feature has gone live

forgotaccount3 16d ago
Create story to add feature flag controlling access to the feature. Immediately create story to remove said feature flag controlling access to the feature and review it during backlog refinements.
chasd00 16d ago
i could see it getting complex with a lot of flags, inevitable you'll run into a situation where more than one flag is combined. something like enabledFeature = (flag1 || flag2 || flag3) && flag4 then, down the road, you remove flag4. Hopefully the above would result in a compile error but you may be in a language or situation where a missing flag4 is interpreted as boolean false. That could cause all kinds of havoc in logical combinations like that are scattered all over the codebase. Even worse would be REST APIs retrieving flag values because who knows what's happening in that service code? Plus, you'd never know there was an issue until users start reporting missing or extra features showing up unless you have e2e tests for every possible combination of feature flags...
- lpribis 16d ago
  Surely the commenter means deleting them in the code, not just the management software. Otherwise, what's the point? You need to find every occurrence of flag4 and remove references to it. So that boolean expression would need to have `&& flag4` removed.
  - chasd00 16d ago
    What I’m saying is there may be references you don’t have access to.

not_a_bot_4sho 16d ago

> Imho excessive feature flag complexity is a symptom of management who are indecisive and mistrusted by the developers. In my experience, engineers aren't using them to account for managerial dithering, they're doing it for safe deployments and experiments and rollouts and such. A product with millions of users can easily have a tens or even hundreds of active switches at any moment (I'm assuming a large engineering team behind said product), and that's not necessarily a bad thing. However, as someone else noted here, you absolutely MUST delete and clean up your flags/gates/whatever when you've completed that effort. That part can be tricky because not everyone has the discipline to pay off tech debt. Usually, a flag/gate should not live in code for more than a few months. If it does, it should have robust justification.