2 ms·

I would really ask HN about how you manage "feature bits" (like the BugFix_123456::IsEnabled()in TFX ) . I have worked in huge code bases (think Windows-like

I would really ask HN about how you manage "feature bits" (like the BugFix_123456::IsEnabled()in TFX ) . I have worked in huge code bases (think Windows-like huge) with policies like that and thus know the pain very well, but cannot think of solutions around it. Most of the time the complexity grows as the code and related modules have to support both codepaths: you cannot really simplify the architecture even if the "bugfix" branch is really conceptually simpler (as it tends to happen). There's also no cleanup policy (not to mention that the developers who do the cleanup ,if ever, will just remove the if and not simplify the surrounding code).

toast0 1y ago
IMHO, first it needs to be stated that feature flags are only truly useful when you have a process to change the flags that's faster than deploying a new version of code. I've seen some environments where a flag configuration deployment is the same work as a code deployment, and so why bother. Also, these things need to be temporary, and you should enforce that somehow. Otherwise, chances are very few permutations are being tested, which makes it hard to use the flexibility you tried to build. Some teams automate this in some fashion... require an expiration date comment, fail the build if it's in past the date, or if you like things spicy, have a bot remove it on expiration. Sometimes you end up with a feature that's done in your code but waiting for something else and you end up with the behavior disabled for a long time. That's not fun, but it's life. Otherwise, I like feature flags to live for about one release... Put it in, push the feature, once it works, remove the ability to turn it off. That should be part of the post-release acceptance process.
jynelson 1y ago
I think this is the natural end state of code bases over time and it’s very hard to fix without dedicating lots of time (and getting buying from management to dedicate that time) https://jyn.dev/technical-debt-is-different-from-technical-risk/ https://jyn.dev/technical-debt-is-different-from-technical-r...

toast0 1y ago

IMHO, first it needs to be stated that feature flags are only truly useful when you have a process to change the flags that's faster than deploying a new version of code. I've seen some environments where a flag configuration deployment is the same work as a code deployment, and so why bother. Also, these things need to be temporary, and you should enforce that somehow. Otherwise, chances are very few permutations are being tested, which makes it hard to use the flexibility you tried to build. Some teams automate this in some fashion... require an expiration date comment, fail the build if it's in past the date, or if you like things spicy, have a bot remove it on expiration. Sometimes you end up with a feature that's done in your code but waiting for something else and you end up with the behavior disabled for a long time. That's not fun, but it's life. Otherwise, I like feature flags to live for about one release... Put it in, push the feature, once it works, remove the ability to turn it off. That should be part of the post-release acceptance process.

jynelson 1y ago

I think this is the natural end state of code bases over time and it’s very hard to fix without dedicating lots of time (and getting buying from management to dedicate that time) https://jyn.dev/technical-debt-is-different-from-technical-risk/ https://jyn.dev/technical-debt-is-different-from-technical-r...