Feature Toggle vs. Feature Flag: The Rise of the Flag

Editor's note: This post has recently been updated from an older version.

The evolution of feature toggles to feature flags and what it holds for the future of software development.

The history of the feature toggle

Jez Humble and Martin Fowler are best known for promoting the separation of feature rollout from code deployment. In the context of continuous delivery, they provided the foundation for a framework that would allow developers to release software faster and with less risk.

Fowler is well known for championing the concept of feature toggles, which are ways to wrap features in conditionals that allow you to toggle features on and off for users. Feature toggles enable developers to take full control of their feature rollouts, dark launch, and roll back poorly performing features. Early feature toggles were effectively release toggles.

This led to the rise of open source feature toggle libraries tailored for specific languages, like Java and PHP. The main purpose of these initial libraries was to allow the quick and easy implementation of basic feature toggling functionality—a boolean value of true or false that would determine the visibility of a code snippet. Moreover, early feature toggle developers had to address the issues of runtime performance, technical debt management, toggle management, and polyglot stacks.

As feature toggles increased in popularity, development teams started to explore advanced functionality using more complex conditions, such as incremental percentage rollouts, granular user targeting, and long-term feature management. With full control of feature releases using more advanced toggle configuration, developers saw the power of releasing new features to beta testers, specific user groups, and gradually ramping up a feature release from 1% to 5% to 100% of users.

Feature toggles, therefore, became less about simply turning a feature on or off. They became more about full feature lifecycle management—managing the feature from development, to release, to sunset.

With this new emphasis on feature management came the rise of the feature flag.

The rise of the feature flag

Although feature toggles and feature flags are used quite interchangeably today, feature flags may be growing into the more appropriate term. At LaunchDarkly, we view toggles as a subset of feature flags and feature management. A toggle or switch implies that something has two states: on and off. Feature management on the other hand includes choosing how your code behaves in the moment, providing far more fine-grained control over your experimentation and feature rollouts.  

When Martin Fowler published Patterns for Managing Source Code Branches in 2020 on feature branching, the term feature flag was used rather than feature toggle as a way to hide a partially built feature. 

If there’s no way to easily hide the partial feature, we can use feature flags. As well as hiding a partially built feature, such flags also allow the feature to be selectively revealed to a subset of users—often handy for a slow roll-out of a new feature.

Many new frameworks are switching to the nomenclature of flag because they support long-term control, percentage rollouts, and multivariate states.

Use cases for feature flags vs. feature toggles

Below are two use cases where a flag is a more appropriate description than a toggle, particularly in the context of enabling DevOps.

Use case 1: A/B testing

Feature flags do not have to be binary, and often are not. With an A/B test, you typically present two variations, but a flag can return multiple values with A/B/N testing: variations like blue, red, green, and purple, which your code can interpret to display different variants of a feature. You could also potentially use flags to release new features using date ranges and numbers. In other words, the feature itself can have more than two states, and these states do not necessarily need to be on or off. The off variation for a feature flag could hide the code changes completely, whereas the blue or red variations will serve different variants. A/B testing is also an example of where people outside of the development team can make use of feature flags. Product managers for instance may use A/B testing to understand how features resonate with their user base and make data-driven decisions to improve user experience.

Use case 2: canary releases

A canary release refers to sharing a feature or a set of features with a subset of users. Canary releases help you minimize risk by having a trusted group of users access a new feature before rolling it out to a wider, higher-risk audience. Feature flags help you precisely identify and judge whether a user has the right level of permissions to see the requested information. Rollbacks, where necessary, are contained to a smaller subset of the user base, so teams can work on debugging problematic new code as soon as possible.

Canary releases differ from A/B testing in that the latter is usually used to understand how users respond to a new feature or code change, whereas canary releases can be used to conduct testing on backend functionality in addition to user-facing features.

Beyond canary releases and incremental rollouts, testing in your production environment is a powerful way to understand the impact of code changes.

A feature flag can be considered a way to manage the full lifecycle of a feature, tracking the progress of a feature from development, to QA, and to production. It can also be a way for you to aggregate performance analytics and metrics and test the impact of a feature on your system’s architecture.

Looking forward

There is no wrong way to categorize a feature toggle or feature flag. What is important is that companies are starting to realize the importance of separating feature rollout from code deployment. This separation enables software to be more adaptive to user needs while also contributing to platform stability.

The spectrum of options available with feature flagging helps to enable progressive delivery. Progressive delivery builds upon the practice of continuous integration and continuous delivery (CI/CD) with robust use of feature flagging and observability to ship code safely and fast. 

The future of software development and continuous delivery highlights the significance of feature release management. A feature release is now no longer an afterthought. It is something that must be built into the development of a feature from its inception to its rollout. Planning a feature release should be integrated into a development team’s workflow.

Feature flag management is critical for effective feature flagging at scale

With feature flags having more advanced functionality than simple on/off or release toggles, the potential for technical debt grows. If you’re just starting out with feature flags, a config file may suffice. As the number of flags and complexity of your configurations increases, outdated or duplicative flags can accumulate quickly in your codebase. Having a robust feature flag management solution helps to keep tech debt associated with flags in check by allowing teams to manage them from one central location.

Feature flags and toggles are not just a best practice for the continuous delivery of software, but are now becoming integral to running a business. With the right feature management platform you can safely test new code to get real feedback and iterate quickly.