How Feature Flag Management Systems Let You Build Apps Faster

It's one of the first things you learn as a new programmer.  At least, I'm assuming it has to be.  So many years have passed between then and now that I can't say I actually remember learning it.  Almost like reading, it just seems like I've always known. I'm talking, of course, about the humble "if" statement.  Along with its implicit companion, "else," the "if" statement undergirds pretty much everything we do as programmers.  Imagine life with a bunch of void statements.  It's like a boring shell script.  Life doesn't get interesting until you add in a little decision logic.

Now, I'll use a relatively fancy term: "feature flags."  You might hear this term tossed around in a variety of contexts.  E-commerce comes to mind.  And, of course, there's the recent DevOps revolution.  If you take an interest in how a tech titan --- like, say, Facebook --- deploys its software, you've probably heard the term. At its core, though, the feature flag is really just an "if" statement.  Out in the wild, there's a bit more to it than that, naturally.  But when you boil it down to its essence, you're talking about a simple "if" --- the same kind you learned about 10 minutes into becoming a programmer. If the flag is enabled, then show shoppers the new "suggested purchases" pop-up.  If the flag is enabled, then show the new dislike button on Facebook.  (Wouldn't that be fun every now and then?)  You deploy some new functionality to production, but you retain the ability to turn it on and off with administrative access.  This allows Facebook to roll out the dislike button, in our latter example. And if enough backlash comes their way, they can turn it off without rolling back or patching the release.

That sounds great, from a business operations perspective.  You can roll things out that come with some risk while having a backup plan.  Anyone doing this long enough has lived through some kind of botched release and the subsequent scramble to roll it back.  With a splitting headache and an incessantly ringing phone, you run SQL script after SQL script as a project manager paces behind you.  Or something like that. Feature flags (or feature toggles) are wonderful because they let you avoid that stressful situation.  Instead of having elaborate rollback and roll-forward gameplans, you have an easy on-off switch. But if you've been doing this a while, you probably also see a downside.  There's nothing like throwing a bunch of flags in your code to make it a maintenance nightmare.  One flag sounds great, but dozens or hundreds?  Who can keep track of all of that?  Your code becomes an incomprehensible mess...doesn't it?

Well, yes, it does become a mess.  At least, it becomes a mess if you implement it ad hoc, without instrumentation or an overarching pattern.  But it doesn't have to. Enter the feature flag management system.  By taking a deliberate, organized approach to managing your feature flags, you can avoid piling up technical debt and creating a mess in your code.  Think of historical cross-cutting application concerns, like IoC containers or logging frameworks.  Done without planning and premeditation, they create messes in code.  But the industry recognizes their value and finds ways to incorporate them while mitigating potential downsides.  So it goes with feature flagging. You can realize the power of the feature flag without turning your code into a dizzying maze of context-dependent conditionals.  And I'd argue that you should do it.  I could cite a number of different reasons, but I'll focus for the remainder of the post on one specific one: do it because it actually makes app development go faster.

It may seem counterintuitive to say that feature flags speed up building your app.  After all, they introduce a form of additional complexity, and any sort of complexity generally slows things down.  But feature flags introduce a form of complexity with ROI, as far as time goes.  You spend time and complexity up front, but it more than pays for itself down the line. For starters, it lets you get your app to market faster.  With traditional software deployments, you unwittingly couple together two forms of risk.  First, you have the risk of difficulty with the actual deployment from a technical perspective.  And secondly, you have the risk of adverse user reaction to new stuff --- angry cries of "Who moved my cheese?!" When you add feature flags, you decouple those two risks.  You can create deployments that don't show changes to the user base.  This lets you get your apps and features into the market without necessarily having to worry about messaging and user reaction.  You can deal with that later, as a business decision.

Each line of code in your codebase is a liability.  That seems weird, since we like to think of building code as a form of construction, but resist that mental model.  Instead, understand that each additional line of code you write offers a new vector for problems and bugs.  The less of it you have out there, the less exposure and risk you have. Feature flags let you run experiments and tighten the feedback loop.  Traditionally, you'd ship a whole slew of features in the form of a release, and then you'd hope people liked and used them.  Once in the software, you tended to need to maintain them forever.  After all, someone out there would eventually use them on a long enough timeline, no matter how poorly conceived. With feature flags, though, you can roll features to some users and see how it goes.  You can then turn them off for everyone quickly, if users react poorly.  That offers a decisive thumbs down on the feature, letting you cull it from your codebase, saving yourself all sorts of downstream maintenance.  A feature flag management system lets you keep your codebase much leaner than it would be, subject to the normal feature bloat.

I'll close with a piece of advice that draws its inspiration from the world of agile coaching and transformations.  If it hurts, do it more.  To understand the philosophy, think of the dentist.  If you only go once a decade, it'll be onerous, making you want to put it off another decade.  But if you go a lot more often, each visit will be only mildly unpleasant.  In software, think of continuous integration as a solution to painful merges. For our purposes, though, think of deployments to production.  Historically, that means a carefully considered, nerve-inducing plan. The very riskiness and pain of the activity tends to make you want to do it less frequently.  And that long time between deploys necessitates a whole series of overhead activities to prep. Now, imagine if you just coded something up, ran a bunch of automated tests on the codebase, and then popped it into production with the push of a button.  All of that going through the pre-release checklist and taking of deep breaths before hitting deploy would go away.  You'd save yourself an awful lot of overhead prep time, and that time would add up. Well, that's what a feature flag management system gets you.  It takes the risk and scariness out of regular pushes to production.  As a result, you'll do them more frequently and largely eliminate the prep activities. A feature flag management system is a technical implementation, to be sure.  But it's also a holistic deployment approach and even a business philosophy.  And that philosophy, simply put, is a philosophy of getting value to your users quickly.