Feature flags (also known as feature toggles, switches, and flippers) are code snippets that function as if/else logic statements, enabling or disabling features within an application.
They are a fundamental tool for developer teams that want precise control over their feature deployments, as well as enabling modern software development practices like progressive delivery, granular user targeting, and feature experimentation.
What are feature flags for?
Feature flags are essential to both feature management and experimentation, allowing teams to control the behavior of an application in real-time. Creating a feature flag involves naming the flag, configuring it, choosing KPIs, setting user targeting, and scheduling the release.
They are central to the goal of fast and continuous software deployment, while allowing for risk mitigation by turning features on and off without having to deploy new code or roll things back, eliminating the complex need to manage multiple branches of code.
At their core, feature flags give engineering teams more control. Features can be built behind a flag until it is ready, and then be released gradually to a small base of users to measure and track stability. For example, developers can preload changes ahead of a data migration or backend infrastructure changes. If issues arise, flags can revert to known-working configurations, simplifying complex migrations.
They also act as a handy killswitch. If a feature drives a drop in conversions, the team can simply turn the flag off and kill the feature. This reduces the risk associated with new deployments, as problematic features can be quickly disabled without impacting the rest of the system.
Feature flags are also a handy tool for product managers to determine release dates and segments of users exposed to a feature. This audience segmentation helps in collecting targeted feedback, iterating quickly based on user responses, and ensuring that features meet user needs and expectations before a full-scale launch.
With Boolean flags, developers have long been able to toggle features on or off, storing only true or false values. Now, advanced feature management solutions allow product managers and quality assurance (QA) teams to update feature flags and run experiments, validate releases, test, and collect feedback, without writing any code.
Additionally, feature flags enable feature experimentation by allowing testing of different feature versions to measure performance against business goals. This data-driven approach validates hypotheses, ensures product quality, and identifies the most impactful variations ahead of release.
Implementing feature flags
There are two main options for implementing feature flags:
- Use developer resources
Traditionally, developers coded feature flags directly into the codebase. However, relying solely on developer resources is not a sustainable or scalable approach.
- Using a feature management system
Feature management systems reduce the burden on developers by providing tools for designing, monitoring, and managing feature-flagged code. Advanced systems offer comprehensive SDK libraries, support for feature variables, mobile app testing, deep reporting, and real-time monitoring.
Key benefits
Feature flags offer numerous advantages for development and product teams, including:
- Reduced risk
Releasing features to an entire user base can introduce bugs, negatively impact performance, and create poor user experiences. feature flags allow gradual feature releases, starting with a trusted user base, minimizing the risk of widespread issues.
- Increased control
Feature flags provide control over who sees a feature and when. This enables the deployment of incomplete features to production and facilitates incremental rollouts, feature variations for user subsets, and feature experiments.
- Improved efficiency and agility
Feature flags separate feature releases from code deployment, boosting developer productivity and fostering an agile environment. Faster feature releases deliver value to users more quickly, improving customer retention and lifetime value while decreasing acquisition costs.
- Cost-effectiveness
Feature flags prevent costly rollbacks and the launch of unwanted features by enabling small-scale validation before a full release. This timely and cost-effective approach ensures quick issue detection and correction.
Best practices
More like this
Now we know why feature flags are important, how do you get the most out of these tools?
- Naming features
Managing feature flags can become challenging if not handled properly from the start. As teams grow, they often accumulate old flags sitting atop stable code that no longer requires toggling. This can lead to a cluttered production environment, diminishing the value of feature flags, which are intended to speed up development and reduce risk.
A common issue is that teams may not know what a particular feature flag does due to non-descriptive, engineering-focused names (e.g., “NEXT_OLD_GEO5”). Instead, give your feature flags human-readable names. For instance, if a flag is for user-facing features, name it something that non-technical users can easily identify, like “Privacy Features – Africa.” This helps ensure that all team members, not just engineers, can effectively manage feature flags.
- Removing stale flags
Another common oversight is the lack of clear internal processes for removing stale flags. Without an agreement on ownership and frequency of cleanup, teams can find themselves overwhelmed by an excessive number of feature flags. This results in technical debt and can negate the benefits of using feature flags. To avoid this, it’s essential to establish a process for removing stale, unnecessary, or outdated feature flags as new ones are introduced and establish who is responsible for this task.
- Feature flags by default
When teams ask how to get started with feature flags, my answer is simple: any code change should be behind a feature flag. By putting all changes behind a flag, teams gain flexibility, and if a change causes issues, you can easily turn it off.
- Operational toggles
While feature flags are often used for release or experiment toggles, operational toggles (ops toggles) are another valuable application. By placing flags around code paths that control key configuration settings, you can quickly respond to production failures, reducing mean time to resolution (MTTR) and simplifying responses to system outages.
- One Flag Does Not Rule Them All
Avoid placing all changes behind a single feature flag. If rolling out a feature to premium users requires both frontend and backend changes, use multiple, smaller flags. This makes it easier to identify issues and test discrete changes during feature development, enhancing overall control and stability.
- First line of defense
Feature flags move control to the feature or release level, empowering teams across the organization to engage with them. This approach improves incident management by allowing immediate toggling of problematic features without waiting for engineering to respond. It also avoids the need for rollbacks, reducing deployment stress and enabling smaller, more frequent deployments.
- Test in production
Testing in production is crucial for understanding how features perform in real-world conditions. By using feature flags, you can release features to live environments, collect data on their performance, and iterate quickly.
- Enforceable governance
Establish scalable procedures to ensure best practices are followed, such as approvals, performance metric verifications, and audit logs. Automating these processes where possible will help maintain order and efficiency as your use of feature flags scales.
Feature management vs feature experimentation
Feature experimentation is the natural evolution of feature management. While feature management provides control over software release processes, feature experimentation enables the launch of better features and products.
It forces teams to measure the value of new features, helping build more effective product roadmaps. Feature management involves turning features on or off for select groups of users, whereas feature experimentation involves testing different features for different users to see which performs best.
The process typically involves collecting research based on user feedback or observations, developing a hypothesis on how a metric could be improved, conducting the experiment by releasing a feature to a certain group or creating different versions of a feature, gathering and analyzing results on how users interact with the feature, and implementing the successful version while continuing to iterate.
Feature experimentation shifts focus from maintaining operations to driving innovation. It optimizes development bandwidth by allowing the creation of prototypes for experimentation, which requires fewer resources than building entire features.
Businesses save precious in-house development resources by discarding feature ideas that fail to move the metrics or offer tangible improvements. It allows for the comparison of features side by side with data, ensuring only the best features reach the entire user base, validating features by tying them to business goals, and implementing successful features quickly.
Let’s get started
Teams typically progress from ad hoc feature releases to hypothesis-driven development. You can get started by implementing some feature flags and eventually graduating to full-scale feature management and finally, experimentation. Your users, and the business, will thank you.
