One of the great debates in the software world is that of build vs. buy. Anyone with a background in software development will tell you that the temptation to reinvent wheels is strong. Sure, any language's standard libraries have optimized list sort functionality. But what's the fun in that? Writing your own would be interesting and fun, and you wouldn't have to rely on some other guy's approach. Okay, that might be a little extreme. But you get the idea. When you build software for a living, you tend to react to obstacles by, well, building software. You do what you're good at. This applies to individuals, and it applies to groups as a whole. But it's important to overcome this tendency and make business decisions rather than emotional ones.
The Business Case for Feature Flags As a Service
When it comes to using previously built software or rolling your own, some things have moved squarely into the "if it exists, don't build it" arena. Obviously, algorithmic basics like the aforementioned list sorting fit the bill here. But here are some actual, real-world kinds of examples:
Logging frameworks --- people just don't do this themselves anymore, and increasingly, they use log aggregation services.
Automated unit test frameworks --- folks are now employing both simple test runners and more exotic continuous testing tools.
Authentication --- this is more and more frequently offered as a service.
ORMs and GUI frameworks --- these have become common.
Yesterday's problem that every shop in the world solved internally became today's offering as a service (or library). Today, I'm going to argue that feature flags should be part of the next generation of such tools. Today, a lot of shops implement their own feature flag implementations and services. But I predict that tomorrow (metaphorically speaking), that will seem silly. Using feature flags as a service in your application is just smart business. Let's take a look at why.
There's a Good Chance You'll Create an Awkward API
Your first foray into feature flags in your software is likely to follow a predictable pattern. You'll want some kind of unprecedented control of your application in production. So you'll implement a feature flag. It'll be a simple little thing --- a boolean guard clause in the code, a simple read from a config file, and an easy on/off toggle. On the business side, people will like the results --- an easy rollback of a new feature or some A/B testing capability. You'll roll it out, and it will be well received all around. So you'll keep doing it. Your single feature flag will become five and then 20. And as that happens, your team will probably not focus on creating a polished, sustainable API for this effort. Instead, it will materialize as a rat's nest of settings in a config file or a database. You'll make plans to do something about it and add it to your product backlog as a "technical debt" card. And we both know it will stay there forever as you keep adding more flags. As you do this, you'll ensure that your feature flag API, such as it is, will always be an awkward afterthought, whereas if you adopt feature flags as a service from the beginning, you'll get a polished, ready-made API instead.
You Don't Want to Build Your Own Feature Flag Dashboard
As you build your own feature flag implementation, your growing pains won't be limited to the application code. You'll also feel it on the monitoring and administration side. I mean, you didn't think you'd manage a file or database table forever, did you? If you're serious about using feature toggles to make your app more customizable and nimble, sooner or later they'll grow beyond your ability to manage in text or data. You'll find yourself building some kind of dashboard functionality. Now think about this for a moment. What started as a few reads to a file and a few Boolean variables in your application is now growing into its own mini-application with a GUI. Your maintenance footprint is growing.
You Have Environments Other Than Prod, You Know
Another thing you'll discover when rolling your own feature flag management system is that you'll pretty quickly want different behaviors in different environments. You probably don't want to run an actual A/B test in staging, for instance. Instead, you just want to know that you can run it. I can't possibly enumerate all of the different things you'll want to do in the various environments of your deployment pipeline. I can only tell you that this will get complicated faster than you might think. And when it does, you'll find yourself either maintaining and source controlling config files on a per-environment basis or else adding environment-specific settings in permutations with your flags. Both of these are ugly options. If you go with feature flags as a service, this capability comes out of the box rather than in fits and starts as you smack your head, realizing you need it yesterday.
Gradual/Segmented CloudBees Feature Managements Are Attractive
On top of building a dashboard and managing environments, we might as well add another task to your to-do list if you roll your own. You'll need to build mechanisms for segmenting your user base. I say this because one of the first things business stakeholders are likely to ask for is more granularity around who sees what and when. They might respond, "Wow, you can turn the new reports feature on and off? That's awesome! Now, let's do a thing where we turn it on only for premium level users at first." Uh oh. Looks like you're going to need to move quickly to tie your home-rolled feature flags in with user roles. And I'll end the suspense for you. It probably won't stop there. With a feature flag management system, the mechanism to group your users exists out of the box, without you needing to build it.
Build the Software Your Users/Customers Want and Not Software They Don't Care About
The last thing I'll mention to consider from a business perspective is opportunity cost. Think of all of the stuff I've said and about how you can get it more quickly with feature flags as a service. You'll get these things quickly and more easily and have fewer maintenance difficulties. But you also won't waste time building dashboards, environment support, and segmentation capabilities. And the time you don't waste doing that is time you do spend building features your users value and will pay for.
Avoid Fumbling Your Way Toward Sophistication
If you just need a temporary flag or you'll only ever have reason to use a handful of them, a feature flag management system may be overkill for you. But if you want to move in the direction of production experimentation, nimble deployment, and heavy flexibility, then you're going to grow your feature toggle capabilities. And if that's the case, you'll want to have a solution that grows with you. Think of it like the aforementioned application logging. When you're doing a greenfield project, you don't roll your own logger and then say, "Well, we'll use a proper one later if we need it." In 2018, you start with one from the beginning. I'm recommending that you do the same with feature flag management. If you want to do this stuff, use feature flags as a service. People are putting their money where their mouth is --- building, selling, and maintaining feature flag management services --- for a reason. Specifically, customers value the capability enough to pay for it. Feature flag management systems are worthwhile. So don't paint yourself into a corner with ad hoc implementations and technical debt. Get it right from the get-go.