11–20 of 51 posts
This is to roll out a feature to a small amount of customers for inital live beta testing before rolling out to all customers?
If so i think this is good. It is documenting the real issue of complexity of comming back to old code and old problems (old being weeks), even if you don't merge it cause of merge hell. At least you have a document of what to do.
And you are culling dead/dangerous code.
If 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.
After all, both are concered with whether user X is allowed to do Y.
Using just one approach might be a clean, maintainable approach.
The original code `if can?(:use_feature_x, user)` is written just once, and then never needed to be removed. The only thing that changes, gradually and cleanly, are the business rules in :use_feature_x (e.g. update the method in your ability.rb, using Ruby CanCan terminology)
"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.
-master---------------*--------------------*--
\-feature-branch---/ /
\-cleanup-branch-----/"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.
This obsession about avoiding technical debt is quite strange. It's a tool to use when it makes sense, like loans in the bank...
This obsession about avoiding technical debt is quite strange. It's a tool to use when it makes sense, like loans in the bank...
Technical debt comes in many forms, like developers will refuse to work on messy code.
Not sayimg you're wrong, could be survivor bias. Most code is thrown cause the messy project specs fail. Might be worth paying the extra for devs on the mess that works.
But I don't like it, messy code is annoying hence why I'll remove technical debt. Which the company will pay for. Another cost of introduced technical debt not cleaned at the time when it's easy.
In 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…
The point is not to make flag cleanup automatic. It is to front-load the work of cleaning it up when the complexities involved are fresh in your mind. That way, when it comes time to clean it up, it is much easier to be more confident that you found all of the edge cases.
To clarify... This is to roll out a feature to a small amount of customers for inital live beta testing before rolling out to all customers? If so i think this is good. It is documenting the real issue of complexity of comming back to old code and old problems (old being weeks), even if you don't merge it cause of merge hell. At least you have a document of what to do. And you are culling dead/dangerous code.
I have very limited experience, and it points to a wide range from a few days to few months. When I stumble about a 1y+ old flag, I tend to delete it (and the dead code path that it comes with).
What's your experience?