<p><a href="https://devops.stackexchange.com/users/513/ken-mugrage">Ken Mugrage</a> posted an interesting comment below my question, with a link to an illuminating explanation of "<a href="https://martinfowler.com/articles/feature-toggles.html" rel="nofollow noreferrer">Feature toggles</a>", with a summary of it like so:</p>

<blockquote>
  <p>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.</p>
</blockquote>

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

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

<ul>
<li>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) ...</li>
<li>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).</li>
</ul>

CC BY-SA 3.0
2017-03-05T14:28:14.987Z
2017-03-05T14:39:05.153Z
2017-04-13T13:01:29.297Z
Pierre.Vriens
<p>Without repeating the content of <a href="https://martinfowler.com/articles/feature-toggles.html" rel="noreferrer">https://martinfowler.com/articles/feature-toggles.html</a>, since it is an amazing in-depth explanation on what feature flag toggles are. I will just focus on the DevOps aspects.</p>

<p>According to the <a href="https://puppet.com/resources/whitepaper/2014-state-devops-report" rel="noreferrer">2014 State of DevOps Report</a> prepared by PuppetLabs, there are four major metrics to measure IT performance:</p>

<ul>
<li>Lead time for changes</li>
<li>Release frequency</li>
<li>Time to restore service</li>
<li>Change fail rate</li>
</ul>

<p>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 $$$.</p>

<p><a href="https://continuousdelivery.com" rel="noreferrer">Continuous Delivery</a> is enabled by these metrics, and has been described in depth in the book <a href="http://rads.stackoverflow.com/amzn/click/0321601912" rel="noreferrer">Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation</a> by Jez Humble.</p>

<p>In context of <a href="https://en.wikipedia.org/wiki/Continuous_delivery" rel="noreferrer">Continuous Delivery</a>, there is an important distinction that differentiates it from <a href="https://en.wikipedia.org/wiki/Continuous_delivery#Relationship_to_continuous_deployment" rel="noreferrer">Continuous Deployment</a>. And that is the decision when to do a <strong>release</strong> of features (to customers).</p>

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

<p>When features are finally finished, doing a <em>release</em> 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.</p>

<p>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 <strong>release frequency</strong> to be higher.</p>

<p><em>This decoupling of <strong>release</strong> and <strong>deploy</strong> is almost impossible to achieve without feature flag toggles.</em></p>

<p>Naturally when no deployment is required to toggle a feature <em>off</em>, then the <strong>time to restore service</strong> is lowered substantially.</p>

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

<hr>

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

<p>Great example of how this is done in real companies can be found at <a href="http://code.flickr.net/2009/12/02/flipping-out/" rel="noreferrer">Flickr</a> (on of the earliest public posts on the subject), and at <a href="https://codeascraft.com/2011/02/04/how-does-etsy-manage-development-and-operations/" rel="noreferrer">Etsy</a>. But many others have adopted the practice and talked about it in length, for example the famous <a href="https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/" rel="noreferrer">engineering culture at Spotify videos</a>. </p>

<p>Etsy are <a href="http://mcfunley.com/design-for-continuous-experimentation" rel="noreferrer">showing off their internal tool to manage feature flags</a>, called Catapult, in multiple presentations found around the web. And Intuit release <a href="https://github.com/intuit/wasabi/" rel="noreferrer">an open-source tool called Wasabi</a> that helps manage feature flags.</p>

CC BY-SA 3.0
2017-03-06T05:50:04.577Z
@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
CC BY-SA 3.0
2017-03-05T14:44:55.467Z
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
CC BY-SA 3.0
2017-03-05T14:48:21.607Z
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 https://en.wikipedia.org/wiki/A/B_testing
Evgeny Zislis
CC BY-SA 3.0
2017-03-05T14:49:57.673Z
OK, that is the finishing touch I was waiting/hoping for, so "accept".
Pierre.Vriens
CC BY-SA 3.0
2017-03-05T14:37:20.063Z
2017-03-05T14:46:28.317Z
2017-03-05T14:46:28.317Z
Evgeny Zislis
<p>There are some questions about <strong><code>feature flag toggles</code></strong>, such as:</p>

<ul>
<li><a href="https://devops.stackexchange.com/q/341/40">How to persuade developers to start using feature flag toggles?</a></li>
<li><a href="https://devops.stackexchange.com/q/162/40">How to use feature flag toggles?</a></li>
</ul>

<p><strong>Questions</strong>:</p>

<ul>
<li>What is actually a "feature flag toggle" (in the context of DevOps)?</li>
<li>Why are they used?</li>
</ul>

CC BY-SA 3.0
2017-03-05T13:41:00.153Z
Reference info, not a direct answer - https://martinfowler.com/articles/feature-toggles.html
Ken Mugrage
CC BY-SA 3.0
2017-03-05T14:57:19.647Z
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
CC BY-SA 3.0
2017-03-05T15:02:18.750Z
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
CC BY-SA 3.0
2017-03-05T15:05:42.520Z
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
<terminology><feature-toggles>
What is a 'Feature Flag Toggle' and when to use them (or not)?
Pierre.Vriens
# What is a 'Feature Flag Toggle' and when to use them (or not)?

(Asked by: username_0 on 2017-03-05)

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

* [How to persuade developers to start using feature flag toggles?](https://devops.stackexchange.com/q/341/40)
* [How to use feature flag toggles?](https://devops.stackexchange.com/q/162/40)

**Questions**:

* What is actually a "feature flag toggle" (in the context of DevOps)?
* Why are they used?

**Tags:** terminology, feature-toggles

> **Comments:**
> **username_1**: Reference info, not a direct answer - https://martinfowler.com/articles/feature-toggles.html  
> **username_0**: 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 ...  
> **username_2**: 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.  
> **username_0**: 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.  

---

## 2 answers

### Answer by username_2 on 2017-03-05. Score: 14 | Accepted answer

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](https://puppet.com/resources/whitepaper/2014-state-devops-report) prepared by PuppetLabs, there are four major metrics to measure IT performance:

* Lead time for changes
* 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](https://continuousdelivery.com) 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](http://rads.stackoverflow.com/amzn/click/0321601912) by Jez Humble.

In context of [Continuous Delivery](https://en.wikipedia.org/wiki/Continuous_delivery), there is an important distinction that differentiates it from [Continuous Deployment](https://en.wikipedia.org/wiki/Continuous_delivery#Relationship_to_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](http://code.flickr.net/2009/12/02/flipping-out/) (on of the earliest public posts on the subject), and at [Etsy](https://codeascraft.com/2011/02/04/how-does-etsy-manage-development-and-operations/). But many others have adopted the practice and talked about it in length, for example the famous [engineering culture at Spotify videos](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/).

Etsy are [showing off their internal tool to manage feature flags](http://mcfunley.com/design-for-continuous-experimentation), called Catapult, in multiple presentations found around the web. And Intuit release [an open-source tool called Wasabi](https://github.com/intuit/wasabi/) that helps manage feature flags.

> **Comments:**
> **username_0**: 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 ...).  
> **username_2**: 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 https://en.wikipedia.org/wiki/A/B_testing  
> **username_0**: OK, that is the finishing touch I was waiting/hoping for, so "accept".  
> **username_3**: @username_0 "Also: what are "A/B experiments" (A=After and B=Before?" - you can probably ask that on this super cool DevOps SE site ;)  

---

### Answer by username_0 on 2017-03-05. Score: 1

[username_1](https://devops.stackexchange.com/users/513/ken-mugrage) posted an interesting comment below my question, with a link to an illuminating explanation of "[Feature toggles](https://martinfowler.com/articles/feature-toggles.html)", 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).


---

