Feature flags: why, when, how?

André Joaquim
4 min readSep 6, 2018

Feature flags — a topic that brings a lot of discussion to the table. Although it might seem an easy concept, it’s rather complex. If misused, the consequences can be very hard to reverse and your codebase might be forever polluted with several feature flags that are either always active or always inactive. This is a small opinion article about feature flags and why, when and how should you use them.

First things first: what is a feature flag (also known as feature toggle)? Pete Hodgson wrote an article that deeply explains feature flags.

Feature Flags are a powerful technique, allowing teams to modify system behavior without changing code. They fall into various usage categories (see Fig.1) […].

They introduce complexity. We can keep that complexity in check by using smart toggle implementation practices and appropriate tools to manage our flags configuration, but we should also aim to constrain the number of flags in our system.

Fig. 1 — Feature flags’ categories: Release, Ops, Permission and Experiment (source)

“Why and when should I use feature flags?” — fellow reader

Feature flags have a wide range of cases where they can be extremely helpful. For example, the following:

  • Control the release of a feature: getting your code merged, tested, and deployed into production and only delivering it to your users when you (or your product manager) want(s)
  • A/B testing: each user is placed into a specific group and at runtime it’s decided which path should the user follow
  • Managing seasonal features: you might want to enable a feature in certain periods of time (p.e. a certain season) or disable a high CPU consumption feature when you’re expecting high traffic on your system

Concluding, using feature flags is very good in a variety of situations. It’s up to you to decide if feature flags fit your use case (or requirements). Don’t fall in the mistake of using feature flags for every feature you build.

One mistake is to confuse feature flags with feature branches. A feature branch can be related to a feature flag, but it can exist without one, and vice-versa. Depending on the type of feature flag you use, it might make sense to use feature branch(es) to help in the development of your feature flag.

“I’ve decided to use feature flags. How should I implement them?” — fellow reader

It depends — the universal answer for vague questions.

Feature flags are not dependent on a programming language, system or architecture. They can be implemented in all kinds of projects — infrastructure, backend, or frontend. Some people argue that you must have an independent service to manage all your flags, some other people state that you can have a separate service for each project. Every approach has its pros and cons.

In my opinion, the most important part is to build a process around implementing a feature flag.

  1. Give it a proper name. Everyone must know the feature flag’s name by heart.
  2. Establish a release plan. You must know all the platforms involved in the feature flag and you must ensure that you enable the feature flag in all projects at the same time to enable the feature.
  3. Implement the feature flag. Depending on the feature’s type (dynamism and longevity), you can choose different approaches to implement the feature flag itself.
  4. Test it together. Having only one feature flag in your product can be tough enough. Imagine having five or six of them at the same time, and having different teams managing (i.e. toggling) them. It’s way to easy to have a set of flags that, together, break your entire product into pieces. That’s why you must test each feature flag separately and together with all other flags.
  5. The crucial part: erase the feature flag. If you get to the conclusion that the feature is meant to live forever, erase it as a feature flag. If you get to the conclusion that the feature sucks, erase everything. If the feature is meant to be toggled from time to time, then keep it.

«In order to keep the number of feature flags manageable a team must be proactive in removing feature flags that are no longer needed»— Pete Hodgson

Concluding…

Feature flags can help you and your team in taking more informed decisions about a feature, shortening your release cycle, performing A/B testing, and empowering people other than engineers allowing them to control releases, among others.

Nevertheless, they don’t come for free: you can possibly end up with dead code everywhere (also known as tech debt), you need to have a very well established feature flag life-cycle management, ensuring platforms remain stable over different feature flags combinations, and the testing complexity that grows harder and harder with each new flag.

If you’re interested in knowing more about feature flags, I recommend the following further reading:

I hope you enjoyed this article, every feedback is welcomed!

--

--

André Joaquim

Product Engineer at Trouva and an Ember.js enthusiast