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.
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:
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
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.
Opinions expressed by DZone contributors are their own.