Feature flags are a simple technique that let you toggle whether a new piece of functionality is available in your software or some aspect of how it behaves.

In this article, I'll discuss why this isn't as crazy of an idea as it sounds, how you can implement a simple feature flag, the different types of feature flags and different ways of triggering each one,

Note: If the term "flag" is confusing you, think of it as a toggle or switch instead. It refers to a boolean (true / false) variable, not a piece of fabric flapping in the wind.

Why use feature flags?

At first glance the idea of a flag sounds a bit odd - after all, if you didn't want a feature to be available, why is it in the code to begin with?

First of all, what works fine for one user may not work right with broader sets of data or interactions in a production environment. You may want to define a beta users only type of feature flag where a feature is only enabled for a subset of users until it is proven to be working without errors.

Secondly, many products have a carefully-coordinated "go live" date. You might want the new code out in production ahead of time to mitigate any extra risks, and then activate a feature once a certain magical date arrives.

Finally, if you frequently release code to production, branch management can be difficult if large features (also called epics) take a long time to complete. You spend more time managing different branches and lose productivity and opportunities to find bugs earlier on in the cycle. Feature flags let you release partial features in an offline state in production, but test them in QA or beta environments before the full feature is ready.

Implementing a Feature Flag

So, what does a feature flag actually look like?

private static IResumeAnalyzer GetResumeAnalyzer()
{
    // Check whatever configuration management this application uses
    if (ConfigHelper.GetBoolean("UseNewAnalyzer"))
    {
        return new RewrittenAnalyzer();
    }
    else
    {
        return new ResumeAnalyzer();
    }
}

In the example above, we pull a setting from whatever configuration file our application framework relies on. If the value of the UseNewAnalyzer is set to true, then the RewrittenAnalyzer will be used, otherwise the legacy version will be used.

Extremely simple code, but the net effect lets us change one file and the application behaves completely differently. Depending on your language and deployment environment, the application may not even need to be restarted.

Ways to Configure Feature Flags

Feature flags don't have to be driven off of a configuration file. There's a number of other options which may make sense in different scenarios.

Common triggers for feature flags include:

Based on values in configuration files (see above example)
Based on values in a database table
Becoming active or inactive on a certain date (or between a range of dates)
Only active for beta users
Only active a certain percentage of the time or for a random subset of users (typically used with A/B testing)
Based on values returned by an external web service call
Managed by an external service such as Launch Darkly

Objections to Feature Flags

Okay, so feature flags make it easier to deploy code offline or to a certain subset of users. That sounds good for quality, but what's the trade off?

Nothing is free, and with feature flags you pay for the price in a few key areas:

Testing

Testing becomes more difficult and lengthy as you now need to make sure you test activating a feature and deactivating a feature. I've seen teams try to adopt feature flags before and only test the feature in an active state, then see a preview environment grind to its knees when the feature was deployed in an offline state.

Additionally, if various features interact with one another and each one has a toggle, you should test all different combinations of different feature states. This is a key reason why I strongly recommend removing old feature flags for features that are now fully online in production or are permanently retired.

Database Schema

If you have a new feature that relies on a database migration script that impacts an existing table, you need to think about how old data will work if the feature is offline, what happens if the feature needs to go from online to offline (or vice versa), and various other concerns.

Usually the best thing to do is to migrate the data with deployment of the new feature toggle - even if that was going to be in an offline state, but this may not be possible in all cases.

Alternatively, you can store a feature version in a column on a table that is being modified so you can distinguish between which rows are associated with the new feature vs the legacy way of doing things. This helps you control migration to and from the new feature state, but the cost of complexity is high.

Configuration Management

The overhead of more configuration means that it's now a little bit harder to administer every environment and track the state of every feature in every environment, potentially leading to confusion or other issues.

Next Steps

Ultimately feature flags are a good thing to consider for major long-lived beta features that need to go out early or for somewhat risky changes which may need a quick rollback option without a code change / deployment.

If you want to learn more about Feature Flags in C#, see my article on FeatureToggle.

While I do use feature flags in some cases, I prefer using the Scientist series of libraries in order to test the effects of new code in production without risking impacting a user.