Does it help to add removal of feature flags to the definition of done of your epics? Then isn't it much the same as staying on top of any kind of tech debt?
So the problem is not the feature flags. If the code/system doesn't get improved bit by bit (is ok to have technical debt), then, whatever the technique, you are going to end in a bad place.
Isn't it only combinatorial explosion if you need to maintain and test all those permutations. But those feature flags have a default value that they get stuck at. So the real remaining problem is pretty much: dead code. Which, again, that's "just" a common type of technical debt.
But hey, I am not arguing for feature flags. No, Sir, please no.
> But hey, I am not arguing for feature flags. No, Sir, please no.
Why do you prefer not to work with feature flags? For context, the product I am working on (which is not very big) uses a simple development/production split to enable or disable features. Several people have recommended using feature flags, but since I have not previously worked on projects that utilized them, I want to learn more about the advantages and disadvantages from a developer's perspective.
I was arguing against the notion that it necessarily leads to a combinatorial explosion. But there is a definitive cost to using feature flags, which I believe can be weighed against other options. In the types of environments where I work, we are able to avoid spending this cost most of the time, without major drawbacks. I'd say, the rare feature flags we have are very short-lived and mostly in the frontend (spa), very rarely in the backend, probably due to a decent team discipline around backward compatibility.
