DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Good CI Is the Key to a Great Developer Onboarding Experience
  • Next-Gen DevOps: Rule-Based AI Auto-Fixes for PMD, Veracode, and Test Failures
  • The Cost of Ignoring Static Code Analysis
  • What Do You Need To Know About DevOps Lifecycle Phases?

Trending

  • Why Stable RAG Answers Can Still Hide Unstable Evidence
  • Slopsquatting: Building a Scanner That Catches AI-Hallucinated Packages Before They Reach Production
  • Persistent Memory for AI Agents Using LangChain's Deep Agents
  • Pragmatica Aether: Let Java Be Java
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. DevOps and CI/CD
  4. Feature Flagging: Falsehoods, Fallacies, and Downright Fictions

Feature Flagging: Falsehoods, Fallacies, and Downright Fictions

The concept of feature flagging is nothing new, and there are some misconceptions about this practice. Read to learn how to separate facts from fiction.

By 
Andrea Echstenkamper user avatar
Andrea Echstenkamper
·
Sep. 21, 21 · Opinion
Likes (1)
Comment
Save
Tweet
Share
10.8K Views

Join the DZone community and get the full member experience.

Join For Free

In a world where every business is essentially a software company, why wouldn’t everyone need a way to make safe and reliable changes to their software? If “feature flags” or “feature toggles” or “gatekeepers” are a proven method used by Facebook or Twitter, why on earth isn’t everyone doing it - or, at least, trying to do it?  

The concept of feature flagging is relatively old, but not standardized in the community, and there are some misconceptions about this practice. Over time, I’ve learned to separate facts from fiction.

Three of the biggest misconceptions and fallacies around feature flags and feature management are that it’s a new and unproven method, it’s meant only for incremental rollout, and a feature management system is something you can build and implement quickly.

Falsehood: Feature Flagging Is Scary and New

Feature flagging has been around for ages; since 2009, in fact, so for over ten years now. 

When DevOps was coined in 2009, Flickr presented a much referred to deck called 10+ Deploys Per Day: Dev and Ops Cooperation, and a large portion of the slides were about feature flags. This was one of the first places feature flagging was ever mentioned. Feature flags and DevOps appeared at the same time and, as it turns out, are tremendously intertwined.  

But this information wasn’t easy to find. The term “feature flags” was far from standardized, and there weren’t many resources out there to help guide you through the distinctions. There are a lot of ways to describe the concept:  

  • Dark launch

  • Feature switches

  • Code switches

  • Config files 

  • Feature toggles

  • Experimentation toggles 

  • Beta testing

This is what Wikipedia still says: "A feature toggle (also feature switch, feature flag, feature gate, feature flipper, conditional feature, etc.)"! A few more feature flag naming variations are not even in the list above.

Martin Fowler wrote a page on feature toggles/flags in 2010, and it has become the top-ranking page for the term (outside of ads, it’s literally the first thing you get when you search “feature flags/toggles”). Pete Hodgson’s seminal piece “A Toggling Tale” wasn’t published on MartinFowler.com until 2017, and that’s when things started to pick up speed. 

Falsehood: Flagging Is Only for Incremental Rollout

The use cases for feature flagging are enormous. The most celebrated use case is usually the first you hear about: wrap something in a feature flag so you can vet and incrementally roll it out to production. And you can find some high-profile examples of beta testing rollouts here.

But there’s so much more you can do. Database migration, anyone?  

You can explore the depth of use cases for feature management here, but here are a few select use cases:

  • Test in production

  • Percentage deployments

  • Kill switch

  • Load shedding

  • Microservices migration

  • A/B testing

  • Entitlements

Falsehood: A Feature Flagging System Is Something You Write In an Afternoon

Feature flagging is easy. Feature management is hard.  Or, at least, feature management is hard enough that you don’t want to spend your own engineering team resources to build, maintain, and improve it. 

I’ll never forget a Hacker News comment, which stemmed from our Series A announcement, where the poster basically said the entire feature management space had essentially jumped the shark. Of course, I did not agree with the sentiment, but I understood the poster’s line of thinking. 

Feature flagging, in its simplest form, can be accomplished with a library. Grab one, wrap up your code, and try it out. Or get something open source and try it for yourself!   

But, there are times when you really want to make sure that your feature flagging efforts work:

  • Across a distributed team

  • Across 12 different languages

  • For your engineering, ops, product, and sales folks

  • For use cases beyond release management

  • With an architecture that scales 

In these cases, there’s a good chance you want to buy that. What level of feature management is right for your team?

It’s been a wild ride to watch feature flagging bubbling up into the mainstream. While there are still many more teams waiting to learn about it, companies working in this space recently received one major validation proof point in the form of analyst legitimacy: research firm Forrester recently launched a report examining the overall market for feature management and experimentation, proving this category is here to stay.

feature flag DevOps Testing

Opinions expressed by DZone contributors are their own.

Related

  • Good CI Is the Key to a Great Developer Onboarding Experience
  • Next-Gen DevOps: Rule-Based AI Auto-Fixes for PMD, Veracode, and Test Failures
  • The Cost of Ignoring Static Code Analysis
  • What Do You Need To Know About DevOps Lifecycle Phases?

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook