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

Question

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

• How to persuade developers to start using feature flag toggles?
• How to use feature flag toggles?

Questions:

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

Answer 1

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:

• 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 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.

Answer 2

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).