How to use feature flags without technical debt
blog.launchdarkly.com
How to use feature flags without technical debt
1–10 of 51 posts
Re: How to use feature flags without technical debt
#2This misses the problem -- often, the new feature is buggy in ways that are not seen in the initial testing. In critical systems, it's often desirable to keep the ability to flip back to the old code around for a couple of release cycles. In a previous life, that has saved my team's bacon.
This comes at a cost, and somehow saying "just delete the flags promptly" is a facile solution; If it was easy to just delete them quickly, it would be even easier to just land the change without the flag, and use rollbacks as your 'undo a bad feature' hammer.
Re: How to use feature flags without technical debt
#3This misses the problem -- often, the new feature is buggy in ways that are not seen in the initial testing. In critical systems, it's often desirable to keep the ability to flip back to the old code around for a couple of release cycles. In a previous life, that has saved my team's bacon. This comes at a cost, and somehow saying "just delete the flags promptly" is a facile solution; If it was easy to just delete the…
Author here.
The point is not to delete the flag promptly, the point is to delete it cleanly, when you are confident the new feature is good.
Re: How to use feature flags without technical debt
#4This misses the problem -- often, the new feature is buggy in ways that are not seen in the initial testing. In critical systems, it's often desirable to keep the ability to flip back to the old code around for a couple of release cycles. In a previous life, that has saved my team's bacon. This comes at a cost, and somehow saying "just delete the flags promptly" is a facile solution; If it was easy to just delete the…
This is similar to my experience, but there have been situations that are similar to what the article posted. Usually however, those are weeded out by the time the deployment to production comes around.
In that case, the QA team is already testing off the feature branch and when they're done testing, you probably don't need a cleanup branch as you've tested the case where you're going to not use it.
It seems that the method posted in the article would be very useful for when you have a strict release cycle with versioning/features in place and you know with pretty good certainty when you are either going to sunset an old feature or require all users to be on the new feature. In that regard, I could see this working very well.
Re: How to use feature flags without technical debt
#5"You will need to merge master back into your cleanup branch periodically, but that is usually easier than it would be to recall all of the context relating to the original change."
Won't there be merge conflicts when you do this the first time as the clean feature branch code be different from the flag based feature on the master? Of course, all the subsequent merges should be conflict-free.
Re: How to use feature flags without technical debt
#6This misses the problem -- often, the new feature is buggy in ways that are not seen in the initial testing. In critical systems, it's often desirable to keep the ability to flip back to the old code around for a couple of release cycles. In a previous life, that has saved my team's bacon. This comes at a cost, and somehow saying "just delete the flags promptly" is a facile solution; If it was easy to just delete the…
Author here. The point is not to delete the flag promptly, the point is to delete it cleanly , when you are confident the new feature is good.
In that case: I don't think I've ever seen any team have problems with how to delete a flag. The struggles tend to be about when.
Re: How to use feature flags without technical debt
#7In my experience with large codebases and multiple teams, another developer might copy that flag into another part of the code to get some desired side-effect.
Yes, this is horrible, but in the real world...
I find you have to grep through the code and think about all the changes that impact your feature flag before systematically removing it. You're cleanup branch isn't being maintained and is could provide a false sense of safety.
Re: How to use feature flags without technical debt
#8If you do feature flags by inserting if blocks throughout your code you will create tech debt anyways. The goal is to have one if block and hide the changed behavior behind interfaces (or polymorphic functions if you are using functional languages). Dependency injection is your friend.
If you don't do this, you won't scale beyond a hand full of feature flags. Chrome has hundreds, for example.
Re: How to use feature flags without technical debt
#9This obsession about avoiding technical debt is quite strange. It's a tool to use when it makes sense, like loans in the bank...
Re: How to use feature flags without technical debt
#10This obsession about avoiding technical debt is quite strange. It's a tool to use when it makes sense, like loans in the bank...
Sure, but it's still a yellow flag. Let the tech debt pile up too much and resolving them feels insurmountable.