5 ms·

That is the one problem we’ve found with feature flags. It’s very easy to forget to gut the “old” parts when they are turned off. In many cases I’ve seen two or

That is the one problem we’ve found with feature flags. It’s very easy to forget to gut the “old” parts when they are turned off. In many cases I’ve seen two or three year-old feature flags whose stale end still remains because the developer and / or team that did the branch never cleaned up. It isn’t usually malicious or lazy… it’s just how things would pan out. Then we’d be nervous removing the old stuff cause who knows why it was left there and who knows if they’d want it back on again…

obstacle1 5y ago
That's not a problem with feature flags per se, it's a problem with lazy implementations of feature flags. Flags should be associated with an expiry date, and company comms tooling should be consistently yelling in some public channel when expired flags still exist in the codebase.
- spookthesunset 5y ago
  > That's not a problem with feature flags per se, it's a problem with lazy implementations of feature flags. Oh absolutely. Feature flags are great, but you definitely need discipline to make sure you clean things up. The longer the unused code rots, the harder it is to remove it.
pkaeding 5y ago
I have found it can be good to 'remove' the flag at the same time you create it, but just don't merge the removal until later. I wrote up this idea in a blog post a while ago, if anyone finds it interesting: https://launchdarkly.com/blog/how-to-use-feature-flags-without-technical-debt https://launchdarkly.com/blog/how-to-use-feature-flags-witho...
- adamredwoods 5y ago
  I've seen this used, but as PRs get added, these 'cleanup' PRs move to the bottom and are usually ignored by other team members. To me, it's about having enough time to do this in a sprint, and that means it really needs to be a post-launch Jira ticket. Which I've seen done maybe once.
  - pkaeding 5y ago
    yeah, this is definitely a risk. I agree that the PR needs to be tracked as a post-launch task. The advantage to this approach is that you do the hard part of removing the flag (ie, thinking through all the parts of the code that need to be cleaned up) while everything is fresh in your mind. Otherwise, you end up spending more time regaining all of the context, and are more likely to leave some vestigial dead code because you aren't sure it isn't needed any more (this is probably less of a risk with languages that lend themselves well to static analysis that can identify dead code, but these tools are never perfect).
ruh-roh 5y ago
Starting new at a startup-with-traction several years ago, I had reason to check out the feature flag configs for my first feature. It was hilarious. - There were hundreds of them, some of them going back to the garage days, multiple years old. Some would turn on/off major functionality core to the product. For example, this was an ecommerce product - one toggle was "show/hide the buy button". (I think that one is staying in.) - This was all hand-rolled, pre-LaunchDarkly stuff, but at least they were all in one place. I diffed Production, Staging, and a one-off UAT environment - the toggles were MASSIVELY different across each.
adamredwoods 5y ago
Same. Feature flags need a yearly audit, but who has bandwidth for that? I'd file it under tech debt / tech health, or a great project for entry level or new hire.

obstacle1 5y ago

That's not a problem with feature flags per se, it's a problem with lazy implementations of feature flags. Flags should be associated with an expiry date, and company comms tooling should be consistently yelling in some public channel when expired flags still exist in the codebase.

spookthesunset 5y ago
> That's not a problem with feature flags per se, it's a problem with lazy implementations of feature flags. Oh absolutely. Feature flags are great, but you definitely need discipline to make sure you clean things up. The longer the unused code rots, the harder it is to remove it.

pkaeding 5y ago

I have found it can be good to 'remove' the flag at the same time you create it, but just don't merge the removal until later. I wrote up this idea in a blog post a while ago, if anyone finds it interesting: https://launchdarkly.com/blog/how-to-use-feature-flags-without-technical-debt https://launchdarkly.com/blog/how-to-use-feature-flags-witho...

adamredwoods 5y ago
I've seen this used, but as PRs get added, these 'cleanup' PRs move to the bottom and are usually ignored by other team members. To me, it's about having enough time to do this in a sprint, and that means it really needs to be a post-launch Jira ticket. Which I've seen done maybe once.
- pkaeding 5y ago
  yeah, this is definitely a risk. I agree that the PR needs to be tracked as a post-launch task. The advantage to this approach is that you do the hard part of removing the flag (ie, thinking through all the parts of the code that need to be cleaned up) while everything is fresh in your mind. Otherwise, you end up spending more time regaining all of the context, and are more likely to leave some vestigial dead code because you aren't sure it isn't needed any more (this is probably less of a risk with languages that lend themselves well to static analysis that can identify dead code, but these tools are never perfect).

ruh-roh 5y ago

Starting new at a startup-with-traction several years ago, I had reason to check out the feature flag configs for my first feature. It was hilarious. - There were hundreds of them, some of them going back to the garage days, multiple years old. Some would turn on/off major functionality core to the product. For example, this was an ecommerce product - one toggle was "show/hide the buy button". (I think that one is staying in.) - This was all hand-rolled, pre-LaunchDarkly stuff, but at least they were all in one place. I diffed Production, Staging, and a one-off UAT environment - the toggles were MASSIVELY different across each.

adamredwoods 5y ago

Same. Feature flags need a yearly audit, but who has bandwidth for that? I'd file it under tech debt / tech health, or a great project for entry level or new hire.