Understanding Feature Flags

At the core of Split is a relatively new engineering practice known by many names: ‘feature toggles’, ‘feature switches’, ‘feature flippers’. To make it simple, from here on out we’ll call them one thing: feature flags.

Related Resources

Using Split Feature Flags in Java
An example look at Split feature flags in-use in the Java language.
Download the guide

Choosing to Build or Buy
Important factors to consider in any controlled rollout solution.
Download the guide

Documentation: Using Feature Flags
Jump into Split's getting started guide in our documentation.
View the docs

What’s a flag?

A flag is just the mechanism used to control a bit of code. Usually it’s an if/else statement, and it’s no different with Split. It’s known as a flag because it provides a signal to the control mechanism, in this case the Split SDK, that a feature is capable of being toggled on and off. As a Split user, you control those conditions via the Split web console.

Why use feature flags?

Feature flags allow developers (or, with Split, anyone else) to have granular control over where and how a feature is available while only needing to maintain one codebase. Without flags, a developer might keep a feature on a feature branch until it’s ready for GA. With feature flags the feature can be part of the master branch from day one, and only visible to a small audience under a strict set of conditions—usually just the engineers working on the project. When the feature is complete, these same flags can be used to slowly roll the feature out to a subset of the user base rather than launching it to everyone all at once. This makes it easy to test new ideas while limiting the scope of impact if things go wrong.

Using the Split Feature Flag

Let’s say you’re working on a new feature in Java, and you’ve decided to name it NEW_FEATURE in Split. In your code you’d paste in the following syntax, auto-generated by Split (or you can just follow the format and write it yourself):

      String treatment = sdk.getTreatment("CUSTOMER_ID","NEW_FEATURE");

      if (treatment.equals("on")) {
          // insert code here to show on treatment
      } else if (treatment.equals("off")) {
          // insert code here to show off treatment
      } else {
          // insert your control treatment code here

In the above example, you’re defining three states: what to show when the condition ‘on’ is met, what to show when the condition ‘off’ is met, and what to show by default if neither of those conditions are present. What you’re not defining are the conditions themselves: those are set up in the release plan you create in the Split UI, or overridden if you decide to kill a feature. Killing a feature just returns it to that third default state.

As you can see in this example, the feature flag is just a switch. In this case it’s a three position switch, but it can work with as many variants of the feature as you’d like to code.

Feature flags and the Split SDK

It’s important to note that, because Split’s SDKs are language-specific, the feature flag is slightly different in each language. You can find an example for every language Split supports in our feature flags documentation.

Why Shouldn’t I Just Build This Myself?

Most big engineering teams are already using feature flags in some internal capacity. Indeed, most of our customers graduated from their own internal flag deployments to Split. So why not build it yourself? Well, for one, Split is ready to go, today. It takes only ten minutes to install, and we’re here to give you a hand getting started if you’d like the help.

But the big reason is, everything that’s difficult about using feature flags at scale, Split makes simple. For example, it can be hard to know what state a feature is in once it’s being controlled by flags: is it safe to remove or still being used? Split shows you which features are getting traffic, and how much. Split’s integrations make it easy to understand the status of any feature, in and out of the app. And Split’s UI makes it easy for anyone to jump in and launch or kill a feature, no coding required. Then there’s the targeting: Split can target a feature and segment your audience based on any attribute in your database. Finally, there’s maintaining all of this architecture at scale. For us, it’s a core competency, and you can always check in on our app’s status.

Further Reading

If you’d like to learn more about feature flags as an engineering principle, here’s a few good resources to get you started.

  • Flickr: The team at Flickr is widely credited with being the first to use the practice of feature flags in production. Their 2009 blog post Flipping Out explains the practice.
  • Facebook: Facebook’s internal tool ‘Gatekeeper’ is one of the most pervasive uses of feature flags in the modern enterprise. Their 2012 engineering blog post Building and Testing at Facebook outlines how they use Gatekeeper to safely test new features.
  • Wikipedia: The wikipedia page for Feature Toggles is a great place to start if you’re looking for more on the concept.