The concept of feature flags is really simple: it’s a conditional block of code that you strategically put somewhere to enable or disable features of your app easily. But knowing the top use cases for feature flags helps you to plan ahead and be more deliberate with their implementation. There are some obvious use cases, but there are also some that maybe you haven’t considered before.
So let’s explore the top feature flag use cases!
We’ve all done it at some point: thrown a conditional around a piece of code to enable or disable it. When it comes to feature flags, this is about as simple as it gets. But it’s far from really taking advantage of the power of feature flags (also called feature toggles) to control functionality in our application.
This guide will walk you through implementing a feature flag in NodeJS using the Rollout service. At the end of the article, you’ll have a dead simple application that integrates with the feature flag service.
Ready? Good. Let’s get going!
Starting With the Basics
First, let’s do some initial setup to make following this article easier. While we could create an entire NodeJS Express web application, we’ll keep things simple and create a basic Hello Rollout application.
First, let’s create a new directory for our project and generate a package.json file using the npm init command.
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.
From a young age, we have a certain appreciation for presentation. Specifically, we like the idea of quietly putting something together, working on it, polishing it, and then unveiling it. Ta-da!
It starts with things like papers and essays assigned in school. Take it home, write it, and then
double triple check it before handing it in. Your grade and your pride both depend on it.
We carry this with us through primary and secondary education and then on into adulthood. For an iconic example, think of Steve Jobs. “Oh, but there is one more thing…”
Steve Jobs mastered the art of maintaining secrecy, followed by a grand unveil. On a stage, he would reveal a polished, secret product, almost like a magician. The effect, like Apple’s success, was undeniable. Grand unveils are the stuff of tech legend.
But, here’s the thing. They’re also the stuff of tech disasters.
When evaluating software quality, feature flags offer a double-edged sword. On the one hand, they can save you from technical debt. But if you’re not careful, they can also bury you in it.
Technical debt, loosely speaking, is the idea that you let your software become suboptimal from a maintenance perspective in order to get to market quickly. Like financial debt, this can be a valuable tool if you manage it well. But it can also get away from you in a hurry if you’re not careful.
Feature flags get you to production more quickly and with less risk. This means that you’re typically going to have good deployment automation in place to accompany them and that you’re also not likely to do horrible things to your codebase in order to hit a deadline. And that’s great.
The downside, however, comes from the fact that feature flags are extra code in your codebase.
When it comes to getting started with feature flags (Android feature flags or just in general), you have to understand that there are degrees of feature flag strategy. A feature flag, in concept, is about as simple as it gets. Slap a conditional around something in your application and call it a day. But that’s far from the end of the story.
In this guide, you’ll need to keep that in mind. I’ll get you to your first Android feature flag as fast as humanly possible so you don’t find yourself bored and frustrated. But after I do that, you must stick around for a deeper understanding, or you’ll turn your application into a quagmire of technical debt. Feature flags require feature flag management.
We’ll get to that, though. Don’t worry. For now, let’s make your very first feature flag.
Get Going with the Basics
First, let’s level set. You might be an old pro with Android development, or you might be new to the whole thing. I’m going to assume the latter so that everyone reading is on equal footing. The first thing you need to do is set up an Android development environment and the “Hello World” app that accompanies it.
At first glance, this title might evoke images of the proverbial tail wagging the dog. Feature toggles, at their core, are “if” statements tied to runtime configurable settings. So am I asking how you adjust your development process to use “if” statements in your code?
No, I’m not doing that.
What I am doing is suggesting that using feature toggles requires more than just code changes. It requires changes in philosophy and approach as well. To illustrate, let me draw a parallel.
The world of physics gives us two interesting concepts: dark matter and dark energy. Cool and mysterious as these sound, they’re really just scientists’ cagey way of saying they have no idea what’s going on in the universe. As an IT director, you have something equally cool-sounding at your disposal, with all the cachet but much less mystery: the dark launch.
Sounds impressive, doesn’t it? It’s like you’re issuing some kind of top-secret software deployment, and you should probably wear sunglasses and a suit while you do it. Okay, so that might overstate things a touch. But it certainly has a nice ring to it.
But what is a dark launch?
You might have heard the term tossed around in context before without fully grasping the meaning. So let’s get specific.
What Is a Dark Launch?
If you google around for the term, you’ll find some rather scientific-sounding definitions. Those can be very precise but not always very clear. So I’ll start with an example instead of a definition.
Your company probably isn’t Facebook. Statistically speaking, this is obviously true. Only a fraction of those reading, if any, work at Facebook. But I’m also talking more philosophically, from a technical capability standpoint.
Perhaps you work somewhere that views IT and software as a cost center. Or maybe you ship software products, but on a much smaller scale. Whatever the differences, you probably don’t face the size, scale, and scrutiny that they do. And, on the flip side, you also probably lack their resources.
But you don’t need to be Facebook to ship software like Facebook. What I mean is, you can learn from them and adopt their techniques. Elements of their approach are, in fact, perfectly suited to your world. You just need to adjust some of your views of what’s feasible and some of your approaches.
Let’s take a look at some lessons you can learn about shipping software.
I’m going to talk in this post about what I see as the future of the agile movement. I realize that this is somewhat of a loaded claim since agile now means all sorts of things to all sorts of people. Depending on who you ask, it’s any one of the following:
- A methodology
- Project management techniques
- A philosophy
- A massive consulting industry
Which of these is it? The answer is “yes.”
But regardless of the current meandering state of affairs, lessons from the history of the agile movement provide lessons for the future of software development. And as you look for where to invest next, both in terms of skills and money, those lessons for the future will help you be competitive.
The Agile Origin Story
Anyone with some years in the industry knows, at least in the vaguest terms, where agile came from. In the early 2000s, a group of successful software consultants got together. All of them were exploring so-called “lightweight” methods for developing software. And so they thought it might make sense to get together to hash out some common themes.
The rest, as they say, is history.
They created a manifesto and published it. Some of the methodologies in question would kind of peter out. But others became iconic things we hear about today, such as Scrum and eXtreme Programming (XP).
The Rise of Big Agile
The origin of agile had a David-and-Goliath kind of feel. On the one hand, you had the Goliath of major software development firms, practicing so-called “waterfall” methodologies. (Or perhaps similar concepts like the Rational Unified Process.) In this world, you planned software for months and then spent years building it, pretending that requirements would never change once you “gathered” them and then froze them for eternity.
That didn’t really work.
So along came David with his agile sensibilities. He won an improbable battle and got the world to see the light. People realized that a better way existed.
But that was 15 years ago.
Now, our metaphorical agile David has made like the great baseball sluggers of the late 1990s. He’s lifted a lot of weights, taken some questionable supplements, and seen his head grow by four hat sizes somehow. David has become Goliath.
Agile is no longer an upstart. It’s the de facto right answer for how to write software. And it’s all the things I listed at the beginning of the post, including a billion-dollar process industry.
Continuous delivery is a relatively new concept for folks that have been in software for a lot of years. Wow, typing that sentence made me feel old, but that’s nothing compared to how old what I’m about to tell you will make me feel.
I remember a time, early in my career, when I used to go sit at “the CD computer.” At the time, I worked for a shop that made manufacturing equipment. I fit into the mix by writing the software that controlled this large machinery. When things went wrong, I tracked them down and fixed them, sometimes resulting in patches going to the field.
And that brings me to the CD computer. I would grab a soda, sit down, and make myself comfortable. Then I’d pull the source code from source control, run a build on that computer with InstallShield, drop the resulting CAB and setup files into the CD burning software, and I’d burn them to a CD. Then I’d increment the minor version number and print a label on the CD with the new version number.
But wait, there’s more. The next thing I’d do would involve printing a bunch of these things. Some I’d put into a binder for myself for traveling to the field. And others I would put into envelopes and mail to our customers.
And that, ladies and gentlemen, was software delivery in the early days of my career. Now, I feel really old.
The Road to Continuous Delivery
The only thing continuous about that mail order software delivery was how much I didn’t like the CD computer. The rest of the process was disjointed, slow, and with a feedback loop so long as arguably not to actually be a loop.
We’ve come a really long way since then.
I can remember the road to get there. First, organizations (my company included) started to move away from CD-based installs to web, and later mobile, applications. Versions became more frequent as well. The major browsers started to have quarterly releases instead of annual ones. Those became monthly and then weekly, and then they stopped bothering with version numbers and informing the user altogether.
Sites like Facebook took off, and they took this to a whole new level. They didn’t just quietly roll out new stuff — they abandoned the concept of product-level releases altogether in favor of granular pushes of features and capabilities.
All of this rode a wave known as continuous delivery.