Understanding Feature Flags in Softwares
What are feature flags?
Feature flags are controls that allow development teams to determine whether a feature is available to users. They can be used across web applications, mobile applications, and even API services.
The inevitable reality
It’s better to have something and not need it than to need it and not have it.
Digital products exist to serve business goals and meet user needs. Both groupd are constantly evolving. However, customer expectations change, business priorities shift, and sometimes teams need to control how features are released, tested, used, and maintained as needs and circumstances change. As product teams, we have to respond to these changes without losing sight of user experience, business objectives, and the speed at which we deliver value.
But here’s the reality: when a business decision changes or a customer requirement needs to be adjusted, the usual process is to go back to the codebase, make the necessary changes, test them, and deploy a new version.
That process takes time, even when the change itself is relatively small.
This where feature flags come in
Feature flags allow teams to change a feature’s availability without requiring a new code deployment each time the decision changes, provided the flag can be updated independently of the deployed code.
The code can already be in place. The team simply controls whether the feature is active and how it behaves amongst other usecases.
What problems do feature flags solve, how do they work, and when do you need them in reality?
Sometimes, a team needs to change how a feature behaves or whether users can access it, but making that change through the usual development and deployment process takes time.
Imagine you’re managing an existing online food ordering app, and your team has just built a new payment option feature. The code is ready, but you don’t want users to access it yet. Maybe the business isn’t ready to launch, or you want to make it available to a specific group of users first.
Without a feature flag, controlling this might require additional code changes and another deployment, which might take time.
Get Aminat Fowoke Balogun👩🏻💻’s stories in your inbox
Join Medium for free to get updates from this writer.
With a feature flag, the team can deploy the code while keeping the feature turned off. When the business is ready, they can turn it on. If something goes wrong after release, they can turn it off again. Here are why feature flags are useful to have:
- Risk mitigation: Let’s say your team releases a new payment option, but you discover that some transactions are failing. The team might be able to fix the issue and deploy a solution within a day, but what happens if it takes longer? Meanwhile, more customers could experience failed transactions using that payment option, lose confidence in the platform, or choose not to use that payment option again. With a feature flag, you can quickly turn off the payment option while the team investigates and fixes the issue. The priority is not just how quickly the team can deliver a fix, but also how quickly you can stop the problem from affecting more customers and protect their trust in your product. The rest of the application and other payment option can continue working while the team resolves the issue.
- Controlled releases i.e A/B Tests: The business might want to introduce the payment option to a small group of users before making it available to everyone as a way to experiment its adoption and usage. A feature flag can enable the feature for a percentage or group of users first, allowing the team to monitor its performance and resolve issues before making a full release to all users.
- Deploying Without Releasing: Imagine your team is still working on the new payment option, but the implementation has already been merged into the main branch. Meanwhile, there are critical bug fixes and other changes that need to be deployed before the payment feature is ready for release. A feature flag allows you to keep the payment option disabled while deploying those other changes. This means you don’t necessarily have to hold up unrelated releases just because one feature isn’t ready for users. Of course, you could argue that unfinished features shouldn’t be merged into the main branch in the first place. That’s a reasonable approach, and techniques like short-lived branches and continuous integration help teams avoid this situation. However, real-world development isn’t always that straightforward. Work may be merged before it’s fully ready, or a feature may need to be deployed before the business is ready to release it. In these situations, a feature flag provides another layer of control over when the functionality becomes available.
- Changing business decisions: Your team has completed the new payment option and planned to launch it on Monday. Over the weekend, the business decides to postpone the launch because the marketing campaign and customer support team aren’t ready. The code has already been deployed, and other updates depend on that release. With a feature flag, you can keep the payment option turned off until the business is ready to launch, without holding up the other updates or needing another deployment just to delay its availability.
These are different problems, but they share a common need: controlling how and when functionality becomes available without tying every decision to a new deployment.
Why are feature flags important?
- Saves time
- Enables safer releases by reducing risks
- Keeps teams in control
- Supports faster decisions
- Improves experimentation
Different use cases of feature flags
- Gradual rollout: Release a feature to a small percentage of users first, monitor how it performs, and gradually make it available to more users.
- A/B testing: Show different versions of a feature to different user groups to compare their performance and understand which experience works better.
- Feature availability: Turn a feature on or off for all users without needing a new deployment each time the decision changes.
- Customer-specific availability: Enable a feature for selected customers or organizations while keeping it disabled for others, based on their needs or agreements.
And this is where I think feature flags deserve a broader conversation. They’re often discussed in the context of A/B testing, but these are all other important use cases.
How are feature flags managed?
Feature flags can be managed in different ways, here are some I am familiar with:
- Environment variables: A flag can be defined as an environment variable, such as
ENABLE_REFFERAL_PAYMENT_OPTION=true. The application reads the value to determine whether the feature should be enabled. This works well for simple, environment-specific controls, such as enabling a feature in testing while keeping it disabled in production. However, changing the value may require restarting or redeploying the application, depending on how it’s configured. - Feature flag management system: Teams can use a dedicated feature flag system to create, manage, and change flags independently of application deployments. This is more useful when teams need dynamic control over features without contact with the development team
Recommendations
Are you using feature flags incorrectly?
I think what matters most is understanding what you’re trying to achieve with them and choosing an approach that fits that need. Here are a few things to keep in mind when implementing feature flags:
- Document them clearly: Team members should understand what each flag controls, why it exists, and what happens when it’s enabled or disabled.
- Test them thoroughly: Test both states of the flag to ensure the application behaves as expected, including what happens when the feature is turned off.
- Secure access to them: Store flag configurations securely and restrict who can change them, especially in production.
- Review and remove obsolete flags: Temporary flags shouldn’t live forever. Once a feature is fully released and the flag is no longer needed, remove it to avoid unnecessary complexity.
- Choose the right approach for the use case: Not every flag serves the same purpose. Consider whether you need a gradual rollout, A/B testing, general feature control, or customer-specific availability before deciding how to implement it.
Conclusion & My Argument
This article started with a conversation with a colleague who felt I was using feature flags incorrectly. I believe it comes down to understanding what you’re trying to achieve with them.
Not every situation requires a feature flag, and there’s no single approach for every use case. We’ve become so accustomed to discussing them in the context of A/B testing and gradual rollouts that we sometimes forget their more fundamental purpose: controlling feature availability.
It’s not just about how feature flags are commonly used, but what you need them to solve.
If you found it useful, that’s a win for me. Feel free to connect with me on Twitter or LinkedIn, and if you’re feeling generous, leave a few claps😇.
