Feature Flag
Noun · Development · Origin: 2010
Definitions
A feature flag (also called a feature toggle) is a configuration mechanism that enables or disables application functionality at runtime without deploying new code. Developers wrap new features in conditional checks that read from a flag store, allowing the feature to be turned on for specific users, percentages of traffic, or environments. Common use cases include gradual rollouts (releasing to 5%, then 20%, then 100% of users), A/B testing, kill switches (instantly disabling a broken feature), and trunk-based development (merging incomplete features behind flags). Platforms like LaunchDarkly, Unleash, and Flagsmith provide management and targeting rules. The main risk is accumulating stale flags that clutter the codebase if teams do not clean them up after full rollout.
In plain English: An on/off switch for features in your app that you can flip without deploying new code — useful for testing features with a small group before releasing to everyone.
Operational feature flags (kill switches for services), release flags (gradual rollouts), experiment flags (A/B tests), and permission flags (premium features) serve different purposes and have different lifecycle expectations. The tech debt comes from not cleaning up flags after they've served their purpose.
Example: 'We have 347 feature flags. 200 of them are for features that shipped two years ago and should have been cleaned up. Each one is a potential confusion source.'
Source: flag taxonomy / tech debt
Etymology
- c. 2000
- Flickr engineers pioneer feature flags to deploy code to production without exposing it to users, enabling continuous deployment
- 2010
- Martin Fowler publishes 'Feature Toggles,' formalizing the pattern and distinguishing release toggles from experiment toggles
- 2015
- LaunchDarkly and other feature flag platforms emerge, turning flags into a managed service and product category
Origin Story
The if-statement that lets you ship code that doesn't run yet
A **feature flag** (or feature toggle) is a conditional that controls whether a piece of functionality is active, without requiring a new deployment. The concept emerged from practices at **Flickr** in the mid-2000s, where the team needed to deploy frequently while keeping unfinished features hidden from users.
John Allspaw and Paul Hammond described the approach in their landmark 2009 Velocity talk, "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr." The key insight: if new code is wrapped in an `if (feature_enabled)` check, you can deploy it to production in an off state, test it with internal users, then gradually roll it out to 1%, 10%, 50%, and finally 100% of users.
Feature flags transformed deployment from a scary, all-or-nothing event into a gradual, reversible process. They spawned an entire industry (LaunchDarkly, Split.io, Flagsmith) and are now standard practice at every major tech company. The main risk: forgetting to clean up old flags, leading to a codebase littered with dead conditional branches.
Coined by: Flickr engineering team (popularized)
Context: Flickr, mid-2000s; formalized at Velocity conference, 2009
Fun fact: Facebook reportedly had over 10,000 active feature flags at one point. Managing them became such a challenge that they built internal tooling to automatically detect and remove stale flags — essentially building software to clean up the mess created by other software.