Coding with Feature Flags

On the surface a Feature Flag is a simple bit of extra code used to wrap some other code, seemingly not a big deal at all. Maybe it’s even seen as a burden or an example of tech debt – more code that just eventually needs to be deleted.

Feature Flags are much more than this though. They are enablers of a streamlined development process, boosters of confidence, and a tool of empowerment for developers, users and clients.

All will be revealed as to how such a humble little technique can yield such power, but before that, what exactly is a Feature Flag?

Note: I’ll use the term ‘Feature Flag’ throughout this article, but they are often referred to by other names too such as Feature Toggles, Feature Flippers, Feature Switches or Feature Conditionals. So if you do come across any of these adjacent terms, just know it’s all the same thing.

What is a Feature Flag?

The (obligatory) definition from Wikipedia describes a feature flag as a software development technique useful for testing work before it has been completed or allowing us to turn on/off features at runtime:

“A feature flag is a technique in software development that attempts to provide an alternative to maintaining multiple branches in source code (known as feature branches), such that a software feature can be tested even before it is completed and ready for release. Feature toggle is used to hide, enable or disable the feature during runtime.” Source

Like Wikipedia, this Hodgson/Fowler article talks about flags as a technique, but also about ‘various usage categories’:

“Feature Toggles (often also referred to as Feature Flags) are a powerful technique, allowing teams to modify system behaviour without changing code. They fall into various usage categories, and it’s important to take that categorisation into account when implementing and managing toggles.” Source

Finally the definition on the featureflags.io website talks about how they allow us to ‘iterate quicker’ and ‘gain more control’:

“Feature flags give a software organization the power to reduce risk, iterate quicker, and gain more control. Feature flags allow you to decouple feature rollout from code deployment.” Source

So from these three definitions we can come up with our own definition, which might look something like this:

So we have a theoretical handle on what a Feature Flag is, but what might one look like in practice?

const MY_NEW_FEATURE = false;

if (MY_NEW_FEATURE === true) {
    loadCoolNewFeature();
}

Simple huh? When you want to enable the flag, you just change the constant to true and your feature is now live!

Doing things this way totally counts, and if you can imagine the constants perhaps living in a separate flag configuration file or something then it’s not too unmanageable. However, you probably do want to make this a little more sophisticated, so how about we make this more dynamic?

function feature_is_enabled(feature_name) {
    // Retrieve flags from an API, database or configuration file.
    const existing_flags = fetch_flags();

    return existing_flags.feature_name || false;
}

if (feature_is_enabled(‘my_new_feature’)) {
    loadCoolNewFeature();
}

Again, not too complicated. Where the flags get saved could be anything from a database, API, even just a configuration file. You can even imagine that some admin User Interface (UI) to manage the flags would fit here too.

Next, let’s look at the various types of Feature Flags and what you might use them for.

What are the different types of feature flag?

In the article on Feature Flags from Hodgson on the Martin Fowler website they define a number of Categories of Toggles. This is extremely useful as it allows us to think about flags as a tool within these different categories. Let’s run through the categories defined by Hodgson and look at how flags can be used within each one.

Experiment Flags

Experiment flags are used for your classic A/B testing or Multivariate testing. If you need more details on what these are and how they are different then Optimizely have a pretty good run through. I’ll try and cover the basics though.

A/B testing is where you’re pitting two versions of a web page or page element against each other to see which performs best. Using a Feature Flag here means you can enable one version simply by turning on the flag and comparing that with the other version where the flag remains disabled. Turning on the flag in this case will almost certainly be dynamic based on some agreed testing criteria, e.g. geography, user role, random choice etc.

Multivariate testing takes this a little further and allows you to test multiple variables rather than a basic split. For example, you may want to test how a headline and leading image compares as opposed to just a leading image or just a headline. Using a flag can help here as you can have each variable be its own flag which becomes enabled based on certain criteria.

So using a Feature Flag can be really useful for setting up these kinds of experiments. Of course, your experiment is only as good as your measurement, so this needs to be factored in too.

Ops Flags

Remember when slashdot was a thing? I mean it still is a thing, but a few years ago it used to be the thing for tech news. I think over recent years Hacker News and reddit have taken over slightly.

In any case, if you had a website or a page on your website that suddenly became popular on one of these platforms you could be in for an interesting time. It’s not uncommon for sites to buckle under the load and go offline during these spikes caused by the syndication on these popular aggregation sites.

How can Feature Flags help here?

Well, it may be that on the page in question there is a specific portion which does some particularly costly processing or loading of data which is causing the site to go down under load. It could even be that you simply need to switch to a much simpler version of the page which is more adept at handling high page load. Wouldn’t it be really useful to be able to ‘flip a switch’ to make the down time stop? That’s what an Ops Flag is about. It’s about being able to react in these situations by turning off these highly dynamic portions of the page or by switching on a ‘light’ version.

How the toggling is done could be a manual thing (presuming the admin panel or database or config file is still accessible to do so!) or it could be automated to switch when the load hits a certain threshold.

Permissioning Flags

Sometimes you wish to enable a feature for a subset of users. This can be for multiple reasons, such as:

• Beta testing with certain beta testers
• Premium features for users with a premium subscription
• Or you may simply want to roll a feature out slowly, starting with a small number of users and eventually moving to rolling out to all

A Feature Flag can be used here to control this. One way in which we’ve seen this managed is through this concept of ‘Conditions’. You can define what conditions your flag should be enabled for and they become enabled through that. Here’s some example pseudo-yaml as to how this might look:

feature_flags:
    GeoRestrictedFeature: # feature will only be enabled for users in certain countries
        conditions:
            geolocation: [‘GB’, ‘US’]
    BetaFeature: # feature will be enabled for users with a role of ‘beta’
        conditions:
            user_role: [‘beta’]
    PremiumFeature: # feature will be enabled for premium users only
        conditions:
            premium_user: true

You can even use this kind of approach to allow users to opt in to certain early-stage features if you want. GitHub do this; for example for their recent notifications re-haul they allowed certain users to opt in to early versions of it:

Release Flags

This is the greatest benefit of using Feature Flags in my opinion, or at least the most interesting as I think it’s what wields the most power.

Feature Flags categorised as release flags allows us to wrap in-progress work – which means we can deploy to production at any time.

It allows us to decouple deployments from releases. This means that the act of deployment is merely putting code on servers. Often nothing will be released, i.e. no new features, no user-facing changes. If you’re like me and take a deep interest in release notes for app updates on your phone, you’ve probably groaned at update notes such as the following:

Although I can’t say for sure, what I imagine they’re doing here (or if not these apps specifically, at least some apps) is regular deploys where often there won’t be any user-facing changes whatsoever. Instead, they’re gearing up for a future release which just becomes them switching on a Feature Flag (I remember one app would even call out explicitly when they were doing this but I couldn’t find a screenshot).

By deploying frequently in this way we’re increasing confidence with every new deployment (they should be small and often) and reducing the risk that any deploy could go awry (large bloated deployments have historically made everyone a little nervous). What we’re doing here is Continuous Delivery.

Continuous Delivery

A full run through of Continuous Delivery is likely a blog post in itself (heck there are books dedicated to it) and so I won’t try and cover everything here, but I think it’s an important topic to cover when talking about Feature Flags.

“Continuous delivery (CD or CDE) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, doing so manually. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.” Source

So Continuous Delivery (CD) is all about deploying little and often. This historically was a problem because you could have multiple developers working on multiple streams of work and you would find that one team might be ready to release one stream, but not the other. Historically this has been solved by one of the following ways:

• Wait for all development streams to be complete. This leads to a heavy, bloated deployment potentially containing lots of code changes and interdependencies. Often this is prone to bugs that often don’t show up until production, and a long and arduous deployment process.
• Work in separate release branches, so that each stream of work can be deployed independently. The problem here is it quickly becomes messy. You have diverged work, hot fixes you need to apply into multiple branches and a high risk of conflicts.

So CD aims to reduce the friction with deployments in order to avoid the pitfalls of the legacy approaches mentioned above.

In the novel The Phoenix Project…

Just a quick warning that the following contains a few spoilers for the novel, so you may wish to skip this next bit if you have plans to read the novel soon.

…they slowly reveal what they believe the secrets are behind a successful IT project.

Much of the focus is on code that isn’t in production being, essentially, waste.

It’s not adding value if it’s not on production.

As part of this they come up with this concept of ‘The Three Ways’ which also gets expanded on in the first part of The DevOps Handbook. Both books go into a whole load of detail about the three ways that I’m not going to be able to give justice to here, so definitely check out the books if you can. However, the basics of the three ways are:

1. The Principle of Flow: the fast and smooth flow of work from development to operations. Delivering value to the customer quickly.

2. The Principle of Feedback: having a short and fast feedback loop so that any issues raised on the right (production) are brought to the left (development) quickly and efficiently.

3. The Principle of Continual Learning & Experimentation: creating a culture of learning and experimenting to avoid any issues relating to ‘standing still is going backwards’.

When it comes to thinking about Feature Flags, it’s the first principle that we’re most interested in.

The Principle of Flow

When thinking about Flow it’s important to consider the concepts of ‘Lead Time’ and ‘Cycle Time’

Lead Time is the time between the appearance of a task on your project board and its progression to being marked as ‘Done’.

Cycle Time is the time that a task is in progress before being marked as ‘Done’.

In order to increase flow you need to reduce both of these things and get code into production as often and smoothly as possible.

Anything not in production is essentially in a queue and at some point will require a handover. Handover in this context is basically the progression of code from one stage to another, for example from a developer’s machine to a testing environment. The problem with these handovers is they are a common cause for delays.

What also happens when these queues get bigger is the deployment gets bigger, with more code to deploy, more configuration changes required, interdependencies to manage etc. What ends up happening is you end up with ‘deployment ceremonies’; these increase risk and decrease confidence.

So queues, handovers and deployment ceremonies all increase lead times and cycle times. We want to decrease these. This is where Feature Flags can help!

Using Feature Flags to increase Flow

In order to increase flow we can deploy to production much more frequently. The issue here is work in progress: how do you ship constantly if work is unfinished? By wrapping it in a feature flag you can easily deploy in-progress code. No more queues of work, no more ceremonies, no more exotic branching techniques to ensure developers aren’t overwriting each others’ work. It’s just, simpler.

One thing it’s worth mentioning at this point is the prerequisite of good testing practices. It’s beyond the scope of this post, but in order to ensure complete confidence of in-progress work, good automated testing practices are a must. This includes basic lint checking to ensure the mechanics of the conditional is correct, but also other aspects of testing to ensure that even code hidden behind a flag doesn’t do anything unexpected that could cause issues elsewhere in the software.

By doing this we decouple deployments from releases so a new feature release becomes the toggling of a flag rather than a big ceremony. As discussed earlier we can use a permissioning approach to roll this out slowly should we want to and, should it become unperformant under load, as we discussed with ops flags we can toggle it off during peak times.

In Summary

Feature Flags needn’t be a complicated thing. Starting off with basic constants is perfectly fine and doing even just this buys you a lot of power as it enables you to take advantage of Release Flags, Continuous Delivery and increased Flow.

There are multiple types or usage categories of Feature Flags. Familiarise yourself with the different ones, and it allows you think in new ways when it comes to writing code in an operations-minded way.

Continuous Delivery is an excellent way of delivering software, and you should read up more on this if you’re not doing so already. The Phoenix Project and The DevOps Handbook are great places to start.

Going Further

So you’re making great use of Feature Flags and practising Continuous Delivery, your software is great, you’re delivering value often, what is the next step?

Well, if you’re doing Continuous Delivery already you’re likely already doing this too, but in case not or just to round this off, it’s worth mentioning Trunk Based Development (TBD).

TBD means that all work should be done against trunk (sometimes called master). This means no long-lived branches, only ever direct commits into master, or short-lived feature branches if following a pull request workflow.

For the complete rundown of Trunk Based Development, the Trunk Based Development site is a great place to visit.

Finally, it’s worth mentioning another CD abbreviation, this time Continuous Deployment. Continuous Deployment takes Continuous Delivery up a notch by automating the deployment process, so essentially any commit into master is instantly deployed to production. Feature Flags are vital to Continuous Deployment and, going back to the concept of flow, should be something we all aspire to.

At Box UK we have a strong team of bespoke software consultants with more than two decades of bespoke software development experience. If you’re interested in finding out more about how we can help you, contact us on +44 (0)20 7439 1900 or email info@boxuk.com.