Feature Toggles — A simple, but unspoken technique

Feature Toggle — also known as a Feature Flag, Feature Flip or Feature Switch — is a simple technique where you can turn on or off a certain feature through configuration.

It is a practice to implement Continuous Integration — in the right way, where the code gets merged and tested for every commit, multiple times a day.

By keeping the toggle off in the production environments, the worry of end users seeing the incomplete feature can be avoided.

def cart_items
if ADD_ANOTHER_COLOR_OF_SAME_PRODUCT
return products_with_same_color
else
return all_products
end
end

In the above code snippet, ADD_ANOTHER_COLOR_OF_SAME_PRODUCT is the feature which can be turned on and off depending upon the environment where it is running such as testing, staging, production etc.

Yes, I know what you are thinking. So many “if…else blocks in the codebase”. Yes, it’s true. It can get complicated. But it’s only for a short period of time. Once the feature is done, the toggle can and should be removed completely.

Experimental Toggles

The release toggles, the toggles to hide partly built features, are a very common use of feature toggle.

Another type of toggle is Experimental Toggles, where the feature is exposed to a set of users for quick experimentation and feedback. This is commonly done using one of the below techniques.

flip, a popular and feature toggle library in the Ruby on Rails world, gives a lot of friendly options to manage feature toggle. Consider flip when you use experimental toggles.

Ops Toggles

A good system should be designed for failures, anything that comes under the “unexpected” category, such as unexpected load on the system or unexpected hardware failure or unexpected network failure.

When you see such surprising behaviors in production, the usual thing to do is to rollback the code. The rolling back of code can be as complicated as merging long-lived branches.

Ops Toggles, another type of Feature Toggle, can be used for degrading a specific feature or for removing a specific feature completely until the situation is brought under control. Using Ops Toggles, you can turn off the feature without rolling back the code. Ops Toggles can be considered as a way to manage Circuit Breakers.

Users might have a degraded experience which is much better than keeping the buggy feature which will continue to embarrass many users.

Keep in mind toggles need to be short lived, except for Ops Toggles. And keep toggles as few as possible.

The Dark side

Every approach has pros and cons.

As we discussed above, Feature Toggles introduces if..else, which can add to the Code Complexity. Ideally, the toggles should exist for a short duration until the experiment is done or until the feature reaches to all the users. But ideal, at times, may be far from reality, which can create issues as shown below.

I would like to relate this to “how to pay off technical debt?”. Different teams might be following different tricks for paying off the technical debt. There is no “silver bullet” that really works for every team because the context is different for each team. But the goal for every team is to reduce the technical debt to the minimum so that it doesn’t affect the predictability or sustainability of software delivery.

The best way to implement is to have an expiry date for the toggles. You can go to the extent of breaking the build if the codebase has any toggles exist beyond the expiry date.

Try out different approaches and see what works and what doesn’t. A common thing with any tool is that when people are new to the tool, there is a probability that they don’t use the tool in the way it was supposed to be used.

More about Feature Toggles:

http://www.multunus.com/blog/2016/03/merge-hells-feature-toggles-rescue/