Feature toggles allow for some part of the code base to be turned on or off at the flip of a software switch. At first glance, they seem like a simple and useful tool to have in your development toolbox. But an overuse of feature toggles combined with a poor implementation will lead to a codebase that is hard to understand, maintain and test.

If you’re not careful, the code will quickly be overrun by statements like this:

if (someFeatureFlag) {
   firstImplementation();
}
else {
   secondImplementation();
}

This is a simplistic implementation and there are better ways to go about encapsulating them. But no matter which strategy is used the code will boil down to some cleaner form of this sample. It’s a nightmare to maintain and debug because a developer needs to understand which combination of flags cause a given outcome to occur.

And then there’s testing. Assuming the code only has 3 feature toggles scattered throughout the service means that there are 9 combinations of feature flags that need to be tested. Many of these combinations are probably unlikely to happen in real life but there should still be a minimum amount of coverage across all of them. Not doing so is asking for Murphy’s Law to come haunt you.

Things get quickly out of hand as you add more and more toggles. Soon enough no one understands the effect one toggle has on the other and the sheer number of combinations make the system hard to maintain at best and extremely brittle at worst. So it’s important to know when to use them and when to steer clear.

Types of Toggles

There’s two broad categories of feature toggles: operational and functional.

Operational toggles are used by DevOps and Support to control the state of the system. Typical operational toggles can be used for:

1. Disabling a service that is failing. It could be failing for any number of reasons, both internal and external to the system. Returning some default error code in the case of a failure helps other applications that consume it to gracefully handle the downtime.
2. Supporting a “maintenance mode” while updates are being performed. You might want to do this for similar reasons as above or simply to inform users that the service is out of operation.

Functional toggles are geared towards manipulating the state of the features that are available to a user:

3. Performing A/B tests to determine what flavor of a feature is more useful to users.
4. Having a finer degree of control over the launch of a new feature by only enabling it for a certain class of user.
5. Completely disabling a feature for legal, financial or any other reason.
6. Having different versions of an application with separate sets of features enabled. As an example, it’s fairly common to have a Free and Paid version of a given application.
7. Telling mobile or web clients what features can and can’t be used. This difference with the previous scenario being that the configuration is stored outside of the client application itself.

When Should You Use Them?

The short answer is as least often as possible. Jim Bird came to the same conclusion three years ago in a very popular article.

Most of the use cases for feature flags can be accomplished in some alternative way, usually by leveraging your infrastruture setup. For example, configuring the load balancer or reverse proxy can be used to solve points  #1, #2, #3. Canary deployments will solve point #4. And Circuit Breakers can be used to solve point #5.

The last two use cases mentioned above, both related to what features should or shouldn’t be enabled for a user, are good candidates for feature toggles. Having multiple versions of an application is no small task and feature toggles definitely help to make that work easier.

Every situation is different though and any of the above scenarios could be a valid reason to use feature toggles. Look before you leap by having a thorough understanding of the goal that you’re striving for and that you’re willing to pay the technical debt of feature toggles.

Best Practices To Follow

There’s a few things that can be done to minimize the risk that toggles introduce.

• Keep the total number of toggles to a minimum. This will simplify testing and reduce the odds of hard to reproduce problems.
• Regularly review the toggles in your system. Any flag that isn’t needed anymore should be removed immediately.
• Have a plan for when you’ll remove a new toggle. Schedule it so that it doesn’t get forgotten.
• Write the code that removes a toggle at the same time as the code that introduces the toggle (in separate branches of course). This helps to make sure the toggle is removed as soon as possible.

Resources

There’s a few sites that you should read thoroughly before writing a single line of code to implement a feature flag.

FeatureFlags.io is the best resources on feature toggles. Their documentation helped me solidify my thoughts on the matter as well as how to avoid the major pitfalls of feature toggling. There are also links to packages that you can use to avoid having to write your own feature flag code.

LaunchDarkly is a major player in the Feature Toggle space. I’ve never had the opportunity to use their SDK myself but their documentation makes it seem like an an easy drop-in for any application to start using toggles.

I highly recommend using an existing SDK to manage your feature toggles. It will allow you to focus on the feature itself — not how it will be toggled on or off. And finally, make sure that you understand Martin Fowler’s article on implementing toggles inside and out if you do decide to write your own toggling logic.