From Wikipedia:
A feature toggle or ‘Feature Flag’ is a technique in software development that attempts to provide an alternative to maintaining multiple branches in source code, such that a software feature can be tested even before it is completed and ready for release. Feature toggle is used to hide, enable or disable the feature during runtime.

In its simplest form, a feature flag is an if/then statement that says if the flag is OFF, use the old feature, and if the flag is ON, use the new feature. You might think, ‘Can't I just have a module or plugin that I turn on and off?’ This is a common approach, but feature flags allow for more nuance. Feature flags are intended to cover multiple scenarios: 

• Enabling features for specific users
• Easy disabling of new features where you may not have yet measured the entire systemic impact
• Control by the end-user or product management
• Gradually disabling older features
• Rolling out features over time to gradually increasing number of users
• Allows flexibility, combined with well organized unit, integration, and end-to-end test suites, the ability to eliminate feature branches in your code repository and always push directly to the main branch

Where feature flags become even more interesting is that they serve both product management and engineering. For product managers, feature flags give them the ability to turn features on and off for different types of customers and allows them to roll that feature out to certain percentages of users. But on the engineering side, where it really helps is more and more companies are getting into microservices where dependency management can be a challenge.

If you’re developing large-scale  projects without feature flags, you should be thoughtful about your dependency management strategy. Let’s say you’re deploying and you need to create a feature. To create this feature, you need to implement something in these eight different services. Imagine you are working on a feature that adds functionality to a backend service that can't be used downstream until the dependent services are ready for it. The code can be pushed to the backend service and deployed to production with the feature flag disabled.

Once all the pieces are deployed with the flag off, you can allow product management to enable it as they see fit.

With a well-built suite of unit, integration, and end-to-end tests (I know e2e testing is a debate all of its own that we won't discuss here), it's safe to push to production because the tests are checking both of the flag states. In this scenario, you're still responsible for fixing any failed builds, but there's no merging, and no merge conflicts. You're constantly deploying because everything is a flag and there are companies that will run with hundreds or thousands of feature flags at a time.

How are feature flags implemented?

There are a few ways to implement feature flags. You could roll your own system, subscribe to a commercial SaaS platform, or you can deploy an open source one.

The available commercial feature flag platforms are easy to get started with. There are very robust SaaS products such as LaunchDarkly and Optimizely that target larger organizations, but as we like to bring enterprise features to projects of any budget, we have also tried less expensive solutions such as Bullet Train and CloudBees.

Generally, feature flags are implemented in two parts:

1. The feature flag service, which serves the flag states and their metadata and allow users to change the flags
2. Backend and frontend client libraries, which allow developers to use the flags

One point of clarification is that feature flags are different from multivariate testing. Frameworks such as Monetate, Optimizely Web, and Google Optimize are that they're focused on marketing optimization, whereas feature flags focus on entire features from both frontend and backend perspectives.

A great resource is FeatureFlags.io from LaunchDarkly.  They cover everything from introduction, getting started, use cases, best practices, and how it all ties in. They even discuss third-party services and libraries.

A (Somewhat) Real-World Example

Let's say you're building an internal company portal, and you're fetching the weather. You have three main parts to this:

Note: Let's assume the "backend" is a monolith. This is fairly common, and there are many other considerations with microservices that aren't suited for a quick example.

1. The frontend application which displays the weather widget
2. The backend application which communicates with the weather API

You want to move to a new weather API, but you don't know how accurate it will be when running in a real-world application.

You take the following steps:

1. Create a new feature flag in your feature flag service, and leave it in the off state
2. Implement the new weather API client in your backend application, which will only activate once the flag is on, exposed through the same internal API endpoint used by the frontend. You are now in a position where the frontend is agnostic to which weather API is used, because the backend will return the same response format.
3. Enable your flag for a percentage of your users, and monitor your logs and analytics
4. Are users within the same geographical area receiving similar data from the new and old weather API?
5. Are you seeing an increase or decrease in errors on the new weather API?
6. Does the new weather API perform better or worse than the old one?
7. Once enabled for all users, you remove the code for the old API and delete the feature flag

Who benefits most from feature flags?

There are two main groups who benefit from feature flags -- engineering and product management.

Within our client base, product managers are the ones turning this on and off and choosing the merchants in production environments. Product managers can choose, based on their conversations with business, how to roll a feature out and who to roll it out to.

For example, they say, `One of our users had issues with this feature. Let's turn it off for them, check the logs, talk to them, and address the issue.’  A few minutes later, the flag is disabled in real-time. This helps engineers because they are able to focus on the tasks at hand and not worry about having to roll back.

The engineering team can deploy code as it's ready across numerous services without wasting time on merge conflicts. While a normal and expected, reducing unnecessary merge conflicts can save a lot of time, especially when we're pushing hundreds of commits per day.

How does this benefit customers? 

It gives the people who are the most in touch with customers, such as product managers, more control over the customer's experience. Now, the customer is defined differently from business to business and in the case of product managers we tend to consider a multi-tenant SaaS product.

But product managers are much closer to the actual customers than the engineers. And so the product managers are the ones doing customer interviews, asking what features they'd like, or they don't like and figuring out what the engineers should be building.  So really putting it in their hands really just gives them that control and that’s a big benefit. 

Are there reasons to not use feature flags?

The developer part of me says there's no reason not to, but realistically, if it introduces a risk or overhead that you're not prepared for, then it's okay not to do it because you can build a control panel into your app.

For example, common open source platforms such as Drupal, Magento, and WordPress utilize plugins or modules. If you're not building your own platform, you'll probably see less benefit because platforms will often have mechanisms to handle the ability to enable or disable features.

If you’d like to learn more about Feature Flags, or how SUMO Heavy can help your organization, set up an Office Hours or reach out at hello@sumoheavy.com.

Photo by Marco Bianchetti on Unsplash