# What is a 'Feature Flag Toggle' and when to use them (or not)?

There are some questions about feature flag toggles, such as:

Questions:

• What is actually a "feature flag toggle" (in the context of DevOps)?
• Why are they used?
• Reference info, not a direct answer - martinfowler.com/articles/feature-toggles.html – Ken Mugrage Mar 5 '17 at 13:41
• I know "asking" about downvote-explanations is not commonly accepted. But whoever downvoted this question anonymously, just know that to me such downvotes are worthless, since these downvotes are cheap (the downvoter does not loose -1 for doing so). Anonymous downvotes of answers is different however ... such downvoter does leave a trace ... – Pierre.Vriens Mar 5 '17 at 14:57
• And I would really love to know why someone felt this question should be closed because of "too broad", when this is in fact a great question that deserves good answers. – Evgeny Zislis Mar 5 '17 at 15:02
• Merci @Evgeny , looks like we're on the same page ... but have you noticed that 1 close vote has been withdrawn? Possibly because Of my most recent edit. – Pierre.Vriens Mar 5 '17 at 15:05

Without repeating the content of https://martinfowler.com/articles/feature-toggles.html, since it is an amazing in-depth explanation on what feature flag toggles are. I will just focus on the DevOps aspects.

According to the 2014 State of DevOps Report prepared by PuppetLabs, there are four major metrics to measure IT performance:

• Release frequency
• Time to restore service
• Change fail rate

These also contribute to organisational performance overall. So it means that if your IT is doing great on these metrics, your bottom line gets more \$.

Continuous Delivery is enabled by these metrics, and has been described in depth in the book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble.

In context of Continuous Delivery, there is an important distinction that differentiates it from Continuous Deployment. And that is the decision when to do a release of features (to customers).

Keeping changes smaller in size, and deploying (copying code) half-baked features to production systems with a feature flag toggled off allows to shorten lead time for changes.

When features are finally finished, doing a release is a decision left to the business. Maybe a release of a new feature needs to be aligned with some marketing, or a release in another part of the business like a feature in the mobile app.

Features can be released using A/B experiements to only a part of the customer base, or to specific people, or even direct to general availability (GA). Although releasing to GA is often done only after there is enough certainty that the feature works as expected. One might argue that this in effect affects release frequency to be higher.

This decoupling of release and deploy is almost impossible to achieve without feature flag toggles.

Naturally when no deployment is required to toggle a feature off, then the time to restore service is lowered substantially.

And by using feature flags that release features to a small slice of the customer base, the change fail rate metric can be improved significantly as well.

So a simple mechanism called feature flag toggles enables much better IT performance, and in turn improves organisational performance overall.

Great example of how this is done in real companies can be found at Flickr (on of the earliest public posts on the subject), and at Etsy. But many others have adopted the practice and talked about it in length, for example the famous engineering culture at Spotify videos.

Etsy are showing off their internal tool to manage feature flags, called Catapult, in multiple presentations found around the web. And Intuit release an open-source tool called Wasabi that helps manage feature flags.

• Merci for this interesting/elaborated answer ... Only 2 things though: the linked article is about "Feature toggles", not "Feature Flag Toggles" (as you wrote in your first paragraph). Would you agree that they are synonyms? If not what's the difference? Also: what are "A/B experiments" (A=After and B=Before? Probably not ...). – Pierre.Vriens Mar 5 '17 at 14:44
• I agree these are synonyms. I just prefer to try and be clear about the name, so there is no ambiguity. I think that "what are a/b experiments" is a question of its own ... but the short answer is that it is two variations that are measured against each other, like in the "Etsy showing off" link. Or explained at en.wikipedia.org/wiki/A/B_testing – Evgeny Zislis Mar 5 '17 at 14:48
• OK, that is the finishing touch I was waiting/hoping for, so "accept". – Pierre.Vriens Mar 5 '17 at 14:49
• @Pierre.Vriens "Also: what are "A/B experiments" (A=After and B=Before?" - you can probably ask that on this super cool DevOps SE site ;) – Dan Cornilescu Mar 6 '17 at 5:50

Ken Mugrage posted an interesting comment below my question, with a link to an illuminating explanation of "Feature toggles", with a summary of it like so:

Feature toggles are a powerful technique, allowing teams to modify system behavior without changing code. They fall into various usage categories, and it's important to take that categorization into account when implementing and managing toggles. Toggles introduce complexity. We can keep that complexity in check by using smart toggle implementation practices and appropriate tools to manage our toggle configuration, but we should also aim to constrain the number of toggles in our system.

Not only does the above summary help to understand what this is about, but it also contains some examples that explain why they are use. And after digesting it a bit further, it seems that "Feature Toggles" and "Feature Flag Toggles" are pretty much a synonym of each other.

But, solution (answer) to the problem (question), changes the problem ... one might ask related questions such as:

• What are the pros/cons about using them? It's a powerful concept, but also a scary one if not used wisely (and secured appropriately) ...
• What could be some examples (good ones and bads ones) where they are used? I can think of quite a few of them, some of them I've used myself quite some time ago (from before DevOps was even a thing).