Working with feature branching reminds me of building a house. You don’t see general contractors insisting on making copies of their own houses when remodeling. Working in the house at the same time forces them to talk to each other and come to an agreement over a conflict. Imagine that a contractor finishes a room, tries to leave, and finds the door suddenly blocked by another wall. The same thing could happen in the code after you’ve been too focused on your feature changes. That’s why communication needs to be enforced—and with feature branches, that’s a thing that can easily get overlooked.
There are some situations in which working exclusively with feature branches might make sense. But generally speaking, if this can be avoided, a team’s productivity and confidence in the code will increase by a factor that you never imagined. For that reason, let’s talk about some of the pitfalls of working with feature branches in your development workflow.
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.