How to use feature flags without technical debt

Hmm. This is a different kind of feature flag than I&#x27;ve used, to solve a different kind of problem.<p>If the feature you&#x27;re writing takes several man years of effort, you can&#x27;t have a feature branch living for several months; continuously keeping it up to date with the trunk is expensive and easy to procrastinate.<p>Migrations are expensive and you want to front load them to make turning the feature on less stressful. And you may want to let customers use the feature on a beta basis for a few months before committing to it, and then it may take a year or more before all customers have moved.<p>For a big feature that cuts across large segments of a big app, I don&#x27;t think there&#x27;s an alternative to if statements.<p>Different apps, different business models, etc.

This misses the problem -- often, the new feature is buggy in ways that are not seen in the initial testing. In critical systems, it&#x27;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&#x27;s bacon.<p>This comes at a cost, and somehow saying &quot;just delete the flags promptly&quot; 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 &#x27;undo a bad feature&#x27; hammer.

To clarify...<p>This is to roll out a feature to a small amount of customers for inital live beta testing before rolling out to all customers?<p>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&#x27;t merge it cause of merge hell. At least you have a document of what to do.<p>And you are culling dead&#x2F;dangerous code.

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.<p>Yes, this is horrible, but in the real world...<p>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&#x27;re cleanup branch isn&#x27;t being maintained and is could provide a false sense of safety.

&quot;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.&quot;<p>Won&#x27;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.

On a tangent, how long-lived are feature toggles usually?<p>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).<p>What&#x27;s your experience?

I&#x27;ve had good success in the past adding @deprecated annotations to the old code when adding new code behind a feature flag.<p>It makes it much easier to come along later and know which functions can be deleted when the decision is made to kill the old code.

Sounds dangerous. Later commits on master might actually add more if(feature-flag) statements, so if you then just mindlessly merge the cleanup branch, you&#x27;ll miss the added ifs.<p>I&#x27;d prefer to create a cleanup branch like any other feature branch only when actually going to clean up, and spend the extra cost getting back in context, studying all the if(feature-flags) from master. Otherwise you might miss some, or you might forget some interaction that you learned after feature deploy.

Haven&#x27;t tried it myself, but why not use authorization libraries instead of specialized &#x27;toggle&#x27; libraries?<p>After all, both are concered with whether user X is allowed to do Y.<p>Using just one approach might be a clean, maintainable approach.<p>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)

In the TXR language interpreter, I have a -C option which takes a numeric argument: it means, simulate the old behaviors of version N. If you don&#x27;t specify -C, you get the latest behavior.<p>Throughout the code, old behaviors are emulated, subject to tests which look similar to this:<p><pre><code> if (opt_compat &amp;&amp; opt_compat &lt; 130) { &#x2F;* simulate 130 and older behavior *&#x2F; } else { &#x2F;* just the new behavior please: -C was not specified, or is at 130 or more. *&#x2F; } </code></pre> I think that tying specific old behavior to a proliferation of specific options is a bad idea. It does provide more flexibility (give me some old behavior in one specific regard, but everything new otherwise), but that flexibility is not all that useful, given its level of &quot;debt&quot;.<p>The purpose of compatibility is to help out the users who are impacted by an incompatible change; it gives them a quick and dirty workaround to be up and running in spite of the upgrade to the newest. They can enjoy some security fix or whatever, without having to rewrite their code <i>now</i>.<p>However, they should put in a plan to fix their code and then stop relying on -C.<p>If users are given individual options, that then encourages a behavior whereby they use new features with emerging releases, yet are perpetually relying on some compatibility behaviors. This leads to ironies: like being on version 150, and starting to a feature that was introduced in 145 and changed incompatibly in 147 and 148---yet at the same time relying on a version 70 behavior emulation of some other feature. Hey we don&#x27;t care that this new thing was broken recently twice before being settled down; we never used it before! But we forever want this other thing to work like it did in version 70, because we did use it in version 70. It&#x27;s like using C++14 move semantics and lambdas, but crying that GCC took away your writable string literals and -fpcc-struct-return (static buffer for structure passing).<p>It&#x27;s very easy to hunt down the opt_compat uses in the source code just by looking for that identifier, and the version numbers are right there. If I decide that no emulation older than 120 will be supported in new releases going forward, I just grep out all the compat switch sites, and remove anything that provided 119 or older compatibility. The debt is quite minimal, and provides quite a bit of value.

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.<p>If you don&#x27;t do this, you won&#x27;t scale beyond a hand full of feature flags. Chrome has hundreds, for example.

This obsession about avoiding technical debt is quite strange. It&#x27;s a tool to use when it makes sense, like loans in the bank...