Is It a Feature Flag or a Feature Toggle?
The evolution of feature toggles to feature flags and what it holds for the future of software development.
History of the Toggle
Jez Humble and Martin Fowler are best known for promoting the separation of feature rollout from code deployment. Within 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 notion of feature toggles, which are ways to wrap features in conditionals that allow you to toggle features on and off for users. This would enable developers to take full control of their feature rollouts, dark launch, and roll back poorly performing features.
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, developers started to explore advanced functionality like incremental percentage rollouts, granular user targeting, and long term feature management. With full control of feature releases, developers saw the power of releasing features to beta testers, specific user groups, and gradually ramp 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 management came the rise of the feature flag.
The Rise of the Flag
Although feature toggles and flags are used quite interchangeably today, feature flags may be growing into the more appropriate term. We view toggles as a subset of feature flags and feature management. Feature management includes choosing how your code behaves in the moment. A toggle or switch implies that something has two states: on and off. Many new frameworks are switching to the nomenclature of flag because they are supporting long term control, percentage rollouts, and multivariate states.
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.”
Although feature toggles and flags are used quite interchangeably today, feature flags may be growing into the more appropriate term. A toggle implies that something has two states: on and off. Many new frameworks are switching to the nomenclature of flag because they are supporting long term control, percentage rollouts, and multivariate states.
Below are two use cases where a flag is a more appropriate description than a toggle.
Feature flags do not have to be binary, and often are not. With an a/b test, you’re typically presenting 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 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 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.
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 test the impact of a feature on your system’s architecture.
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 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.
Feature flags and toggles are now becoming integral to running a business, not just a best practice for the continuous delivery of software.