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.

▲

not_a_bot_4sho 2 hours ago | parent | next [-]

> 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.

▲

Gigachad 4 hours ago | parent | prev | next [-]

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

	▲	chasd00 26 minutes ago \| parent \| next [-]
		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...
	▲	forgotaccount3 4 hours ago \| parent \| prev [-]
		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.

▲

Lucasoato 4 hours ago | parent | prev [-]

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.