What is a “feature flag”?

Question

High Scalability mentions feature flags here:

5 things toxic to scalability, \"5. Lack of Feature Flags\"

What exactly are feature flags?

Answer 1

There are a lot of great answers here, all driving at the important, basic definition popularized in the Martin Fowler post:

They're bits of code that "[allow] teams to modify system behavior without changing code."

So we've historically thought of them as represented by the pseudo-code:

if(app_settings["beta-mode"] == "true")
  showAwesomeNewGui();
else
  sameOldSnoozeFeset();

That's a totally accurate way to think of it, and both Matt and Adil expand on it nicely with a variety of tactical use cases for the feature flag.

But I'd like to offer a revised definition that reflects how reality has evolved in the six years and change since dotnetdev asked the original question. I work for Rollout.io, a feature flag platform, so I've had a front-row seat for this evolution.

Simply put, feature flags aren't any longer just a way to turn bits of functionality on and off in your application. That's like answering "what is an invoice line item" by saying "it's a description and an amount of currency." True, but it doesn't drive at the broader point of the invoice itself.

Feature flags are the tactical bits of an overarching strategic solution in modern software. They're the means by which you defer important decision logic in your code until runtime when you have more information. And, perhaps most importantly, they don't just occur in isolation any longer, with a single check to see if the version number is greater than 2.7 or not; organizations that use them are typically including them as part of a comprehensive, system-wide product approach.

As others have mentioned, Facebook and LinkedIn pioneered this, but in 2018, a whole lot of organizations are doing it. They're deferring decision logic questions for runtime as part of development strategy, operations strategy (or DevOps strategy, if you want), and product strategy. Here are examples of such questions.

• Who should see the new admin screen that we're rolling out, and when?
• What level of membership is required to unlock this Easter egg?
• When should we cutover to the new database?
• Should we put a picture of a cheetah or an eagle on the checkout button to enhance conversions?

To have an application that defers a significant number of such decisions until runtime, you can't throw feature flags into your application in ad-hoc fashion or you'll bury yourself in technical debt. You need, these days, to have a comprehensive feature flag management strategy, which includes a few different components.

• Toggle points are used to switch behavior for new features.
• Multiple toggle points come together to form a toggle router. A toggle router determines the state of a feature.
• Toggle context provides the toggle router the necessary contextual information (e.g., specific user).
• Toggle configuration provides the toggle router information about the environment.

So, in the end, what are feature flags?

Well, they're an important part of a broader strategy to having an application that's adaptable to both technical and market needs.