What are feature flags and why do you need them?

Features flags (or feature toggles) are a mechanism that allows to enable or disable features (pieces of code) without deploying a new version of the app. You control the visibility of a single feature or even whole pages in the app. 

From the developer’s perspective, the feature flag is an additional if statement in code. The only difference is that the conditions are controlled outside the app. 

That’s why I call feature flags “ifs as a service”.

There are a lot of services that help you with feature flags management but, after reviewing the available options, I highly recommend LaunchDarkly. You can use LaunchDarkly in both web and mobile development. This tool allows you to set different values for a flag, percentage rollout, and so much more more. I’m using LaunchDarkly for over a year now and I couldn’t be happier with it.

Feature flagging best practices for your application

You decided that you need a flag in your system and want to implement this correctly. Here’s what you need to focus on.  

Invest time in good naming conventions

When working with feature flags it is crucial to invest time in good naming. People say that naming variables are one of the hardest things in programming. With normal variables, you can always check the file and other variables for context. But with feature flag naming is the only thing you have to work with. Depending on the name you have to know the purpose of this flag. For example: 

The more details you provide in the name, the better. 

Don’t use disable/hide in flag name

I don’t recommend using negative forms in if’s conditions. It is hard to read and requires more effort to use. Like with this example:

With one flag it is still easy to decode the meaning. But what if there is more than one flag in condition? 

It is also very frustrating when you want to set a proper flag value. Imagine: “This is disabled when I give true value, so to enable this on production I have to give false value”. False value to enable flag is unintuitive.

Create team naming conventions for flags

This is an extension of the previous paragraph. Get an entire team on board and write down conventions and standards for your flags. Here’s what you should consider:

• adding team name to flag (it is easier to find people responsible for flags),
• adding a prefix to the flag name (e.g temp, rollout, experiment, config file, etc.) will simplify flag management and remove old flags,
• camelCase or snake_case,
• other naming conventions that you already use in your projects.

Describe flag role 

A good name is a minimal requirement for the flag to be usable. But I highly recommend adding some description to the flag. This is information for you and other teammates about why this flag was created. It looks unnecessary when you create this, but believe me – after weeks/months/years you won’t remember why you created this flag. Description can be added directly in the software you use for flags, but you can also create an additional document.

Create a document for tracking purposes

It is easy to add a new flag but it’s hard to track all of them. From my experience, developers forget about flags just after finishing their tasks. Sometimes they are reminded about the same feature flags when a bug occurs. And trust me when I say that removing the flag when no one remembers why it was created in the first place is the worst task imaginable. Especially when the flag creator doesn’t work in the company anymore or the response product team was transformed into another. 

What information you should track:

• flag name,
• responsible team,
• ticket where feature toggles were introduced (or the context why the flag was introduced),
• expected end-of-life date,
• any other notes.

Make audits

Unfortunately, creating a document is not enough. It is an excellent practice to make regular document audits. I recommend at least one check per year or every six months. During this audit, you should check if:

• every flag is well described,
• every flag is in this document,
• you still need your temporary flags (temp, rollout, experiment),
• unnecessary flags were removed. 

Benefits of a feature flag implemented into your app 

Feature flags have several very encouraging advantages.

In my opinion, the best profit is that feature flags separate code from visibility to the user.

Merging new features/improvements to code doesn’t mean that every user will see this in-app. This way you gain full control over the feature lifecycle (including feature visibility) and reduce the number of critical bugs on production. 

Let’s see more feature flagging profits in more detail.

Release now, activate later

You don’t need additional branches for new features and can merge changes in code (new features/improvements) directly to the main branch. This removes lots of problems on the developer side:

• you don’t have to sync the feature branch with the main,
• a new feature is always in sync with other changes,
• no code conflicts,
• easier to make changes to the whole application (e.g library updates),
• all changes are small and code review is quick.

There’s a nice upside from a business perspective too. Developers can merge recently-added features when they think they’re ready. Then a manager decides if the feature release process will happen now or if it needs to wait a bit longer for a better opportunity. To illustrate this example: developers finished a new feature for an online shop but it’s a week before Black Friday – a day of massive user traffic. Is it better to introduce this feature before or after Black Friday? Will it confuse the users or make shopping easier for them?

Security button

Feature flags work as a security switch – if there’s anything wrong with new functionality, you can disable it with one click. 

You probably experienced testing new features. It’s a complicated process and needs lots of experience from the tester. Nonetheless, no matter what you do, from time to time you will omit a bug causing problems in the production environment. In a normal workflow, spotting an error on production means debugging. Then you’ll spend some time fixing and deploying a new version. If it is a critical error for user-facing features, people won’t be able to use your app for several hours, causing loss to the business. 

If you use feature flags instead, you can first disable a given feature, giving teams all the time they need to work on solving this issue, and if necessary, modify system behavior. Feature flag management is very easy, and feature switches take minutes, not hours. 

Conditional access

Perfect for international apps that have a user base from around the globe. Due to various circumstances (e.g. legal issues), users in one country see different options/features than in others. Thanks to the feature flag system you will control the visibility of given parts of the app for specific conditions like country, language, currency, preferences, etc.

Remote configuration

This is slightly similar to conditional access but has a different purpose. Feature flag can be more than a boolean value. It can also be other types, like strings and numbers used to create a remote configuration for the feature. Now you can change configuration on the fly and redirect the users to different features. 

Canary deployments

Canary deployment is one of the safe ways to deploy a new version of the app to users. You roll out a new version to a small number of users and monitor if everything is working well. Gradually increase the number of users until the entire user base is moved to the new version. With a feature flag, you can do this with a single feature. You can configure how many users will see a certain feature. Use this as an extended Quality Assurance test to check the recent feature before you release it to all users.

A/B tests

The same mechanism can be used for A/B tests – two versions of the same feature/page/message to see which works better for the user. You can use feature flag percentage rollout to move some users to version A and the rest to version B. Remember to log which version users see and what they do there. It is necessary to create a summary after the experiment. After the end date, you should remove all experiment toggles. After creating the feature flags for A/B tests, I recommend adding an additional ticket to remove the flags and move them to one of the future sprints.

Disadvantages of feature flags 

All that glitters is not gold! Feature flags are not ducktape or WD40 that solve all problems. Feature toggling has its own set of issues that you have to consider to avoid feature flag hell. 

Addictive

From a business perspective, feature flags are very addictive. Now the managers don’t have to wait for developers to switch features on and off, they can do it themselves. I’ve already stumbled upon managers who would love to control access to basically everything using feature flags. More control doesn’t necessarily mean a good thing if they lack technical knowledge. Hence, the role of developers is to use a feature flag only when it is needed. Otherwise, you will introduce much technical debt.

Introducing technical debt

Do you remember that the feature flag has to be implemented in code using if statements? If statements always introduce debt as you need to control it and provide default behavior. 

Another problem is old, not used flags that were implemented in the past but are not necessary anymore. If you don’t need these feature flags, just delete them. Be very careful not to create more complicated ifs statements that use the same flags because removing them afterward will be harder. 

Unexpected dependencies

It is easy to control code when you have one flag. But after some time it will be two feature flags and accumulate to dozen or hundreds of different flags. You must know the connections between them in order to test them properly. 

Imagine that you have to enable five flags to the right values to get access to a feature. Increasing the number of flags will lead to more user paths in the app. You have to pay attention to all of them, or you will create a dead end for the user.

Hard to debug

Unexpected dependencies make debugging much more complicated as you have to know all flags state to reproduce bugs. A small change in the flag will cause different results. You must not only have good application monitoring implemented to detect where the user is having problems but also keep track of what unique set of flags that particular user has enabled to repeat the bug and fix it accordingly.

I can’t imagine my work without feature toggles anymore

I’ve been using feature flags for over a year now and I can’t imagine creating advanced projects without them. I lost count of how many times feature flags saved us from critical production errors with incredible testing speed. 

If you follow my tips, adding new features to users will be easier and less stressful, so I highly recommend you check feature flags before your next production release. 

The final thoughts: 

• feature flags are perfect when you want to have control over whether to display new  functionality or not to the end user,
• don’t add a feature flag automatically to every feature – add these only when required,
• invest time in good naming convention and stick to it, 
• NEVER use negative values to enable a flag, 
• track your feature flags, 
• check from time to time if you still need your temporary flags or you can remove them,
• learn to say “No” when the product manager wants an unnecessary feature flag, 
• remember about logging information about flags when using this feature.