A Brief History of Feature Flags

Once upon a time, developers just shipped code and prayed. Then someone realized, “Hey, what if we just… didn’t?” Thus, the feature flag was born. Early flags were just if statements—no, really. “If (isAprilFools) { breakEverything(); }” was the original MVP.

The Early Days: Duct Tape and #ifdef

Before anyone gave this practice a fancy name, developers were already hardcoding environment checks and commenting out chunks of code before a release. C and C++ shops used preprocessor directives like #ifdef ENABLE_DARK_MODE to compile different versions of the app. It worked, sort of. It also made the codebase look like abstract art.

In the early 2000s, big companies like Google, Facebook, and Amazon started rolling out changes to small subsets of users. They didn’t have a catchy name for it either; they just didn’t want to break their entire user base in one shot. Smart.

Getting Serious: Continuous Delivery and Fowler’s Blessing

The practice got its proper name and legitimacy when Martin Fowler first wrote about feature toggles around 2010, cataloging the different types and explaining the tradeoffs — a piece he’s since expanded into the definitive reference on the subject. (martinfowler.com) Suddenly everyone had a vocabulary for what they’d been doing informally for years.

Around the same time, the continuous delivery movement was picking up steam. Jez Humble and David Farley’s book Continuous Delivery (2010) popularized the idea of separating code deployment from feature release. Feature flags were the natural mechanism for making that happen. You could merge to main every day, ship to production constantly, and still control what users actually saw.

The SaaS Era: Someone Will Flip Your Booleans

As feature flags became standard practice, the tooling caught up. Companies like LaunchDarkly, Split.io, and Optimizely built entire platforms around managing flags at scale — user segmentation, percentage rollouts, kill switches, A/B test analysis, audit logs. The humble if statement had grown up. (These days you can also self-host something more lightweight — but I’m obviously not biased.)

Open-source libraries followed. Microsoft shipped Microsoft.FeatureManagement as a first-class NuGet package, integrating directly with ASP.NET Core’s configuration system. You no longer had to roll your own flag infrastructure from scratch unless you really wanted to.

The Lesson

Feature flags went from a hack to a discipline. What started as a desperate if statement in a release branch is now a cornerstone of modern software delivery. The tools changed, the scale changed, but the core idea stayed the same: ship the code, but control what users see.

So next time you wrap a feature in an if, remember: you’re standing on the shoulders of giants. Or at least on the shoulders of developers who didn’t want to get paged at 2am.

History: doomed to repeat it. Unless you use feature flags.