5 ms·
It is much the same, which is to say, doesn't get done.
by ironmagma 4y ago
It is much the same, which is to say, doesn't get done.
- MiyamotoAkira 4y agoSo 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.
- ironmagma 4y agoExcept that most technical debt does not suffer from combinatorial explosion. Feature flags do.
- sverhagen 4y agoIsn'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.
- Klaster_1 4y ago> 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.
- sverhagen 4y agoI 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.