What are feature flags and why are they important in software development?

Feature flags allow you to release, test, and manage features and functionality across your application without changing the source code. Organizations use added control and flexibility to deliver more and higher quality features with reduced cost, time, and risk.

What are feature flags?

Feature flags are a DevOps best practice that you might see also referred to as “feature toggles”, “switches”, “flippers”, or “bits”.

In short, feature flags are a software engineering technique that turns features or functionality on or off without modifying the source code or requiring a redeploy. 

This means you can release and test new features by making it available to a specific group of users, or no users at all, with the power to immediately turn it off without any risk to the rest of your application.

The control that feature flags allow means that they’re already/becoming a popular superpower in feature lifecycle management. Combined with feature management platforms and processes, they can enable a cultural shift within organizations towards more agile and experimental development and ways of serving users.

How do feature flags work?

Within your code, feature flags work with simple statements that check if your new feature is to be enabled or not. You might hear this type of statement being referred to as a conditional but essentially feature flags are an “if this, then that” statement.

The new code exists in your production deployment but, until switched on, the code will be skipped and sit there without being released until you switch it on. This is done either by a software engineer in the code or anyone who has access through a feature management platform.

Operationally, feature flags work by separating your deployments and releases. Historically these were combined and this naturally carried a lot of risk. To try and mitigate this, it became common practice to bundle releases, grouping your changes and new features to be released all together every week or month, and so on. However, if anything was broken, your entire release had to be rolled back.

Feature flags mean that your changes are deployed but not released until they match your set criteria or when manually switched on.

This means changes can be continuous, at speed, and with less risk.

Most organizations benefit from utilizing feature flags with a feature management platform. Combining feature flags with automated monitoring and process management give teams the most powerful results. The easy-to-understand context a platform can provide can drive and even democratize your feature lifecycles.

Feature flags vs. feature branches

With similar names, and often used with similar intentions, feature flags and feature branches have key operational and outcome differences that developer teams should consider.

A feature branch is a workflow (a sequence of processes coming to completion) within a Git repository. This workflow allows you to separate the code of a new feature in development into its own branch instead of the main branch, IE the main codebase. This means that you reduce the risk of having broken code in your main codebase, both as you’re working on it as well as after deployment.

It’s also popular because it allows people to request reviews and sign-offs before changes are merged into the main branch.

So, do you still need feature flags if you utilize feature branches?

Feature flags are a powerful tool that can be used with feature branches. To understand the capability difference we need to look at the downfalls of relying on feature branches alone.

In short, it’s about scale, complexity, and control. Just like on a real tree, branches have a way of growing and sprouting in all directions. These branches can become dated and full of numerous commits, and the burden of continuously updating them before they hit your main codebase can be an operational headache, to say the least.

Organizations can end up spending way more resources on updating and maintaining all these feature branches. Often they’d be better suited to test and manage feature rollout in a live, fully contextual environment of the app. 

Feature flags allow you to do this at speed and, critically, while maintaining the reassurance that you don’t bring risk to your main codebase. 

How you use feature flags depends on the size and complexity of your teams and applications you’re working on, as well as the maturity of your DevOps and wider product development culture.

Why are feature flags important in software development?

Feature flags are important because they can

• Improve user experience
• Level-up your QA
• Reduce risk
• Speed up operations and release cycles
• Enable more powerful testing and experimentation
• Speed up operations and release cycles

Improve user experience

Feature flags give you more control over what is released, to whom, and when. This means you have more control over the user experience of your end product.

Instead of making release decisions based mostly on operational constraints and risk fears, you have the control to make features available based on what makes the most sense for specific users as well as your business goals. For example, releases timed to be inline with marketing campaigns, customer support, and product marketing efforts.

Feature flags also allow you to offer different experiences of your product depending on who the user is. You can turn on features, sets of features, or whole areas of functionality for different user groups depending on their needs.

Anything that allows you to improve QA, testing, speed, and risk mitigation is also a win for the end result of a better user experience.

Level-up your QA

Feature flags are a powerful tool for quality assurance (QA) as they allow you to test feature behaviors under specific conditions, to select users, or no users at all. Features exist but they are as visible and accessible as you want them to be at any given time.

Critically, these tests are happening within the full context of your live product, as your users would experience it.

Merging frequently with automated testing can help prevent breaking anything else and you can disable the new code immediately with little to no user exposure.

Reduce risk

Increasing your control of feature visibility while unaffecting the source code inherently reduces your risk of breakages, rollbacks, downtime, and stress for your teams and users.

Not only is your testing and QA process improved but, if you do see issues in an area of your application, you can disable that feature or functionality at speed and with full control. This decreases the time needed to fix an issue with a key DORA (DevOps Research and Assessment) metric.

You can set up feature flags to disable whole feature sets, applications, or websites if urgent maintenance is needed. Importantly, you have the control to do this for certain user groups at different times. This allows both the “space” to fix any issues while managing the scope of who is affected.

Migrations are a great example use case for reducing risk with feature flags. A phased rollout of feature flags means you can limit the impact on your systems, performance and your end users.

This type of phasing release is often referred to as a canary release, in which feature flags can play a pivotal role.

Speed up operations release cycles

Feature flags allow you to release, test and rollback features at speed. This means your teams are able to work with a stronger mindset of action and experimentation. Especially when coupled with a feature management platform, you can focus on making and managing change with less burden of process and risk management.

You can reduce complicated code integrations and heavy deployments, even with multiple teams working on overlapping parts of complex applications. You can also set up automated feature flags to give access to or disable features based on user or system events. 

Moving to a more CI/CD (Continuous Integration and Continuous Development) way of working with feature flags means you can focus on imprioving your application more frequently with a more reliable delivery process.

Enable testing and experimenting

A/B testing is a great example of the power of feature flags. Use your quick control of who has access to what to understand how and when users are interacting with your features. Which functionalities are serving them best? In what circumstances are new features helping or hindering your users? How are different features interacting with one another at different times?

Set up testing to serve new features to specific groups of your power users or target demographics without any risk to your build or visibility to other users.

With more power to test with less risk, teams outside of the product teams are also enabled to adopt an agile and experimentation mindset. Especially when used within a feature management platform, feature flags allow stakeholders across your organization to be a bigger part of the feature release cycle.