The Top 5 Use Cases for Feature Flags

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!

Have you ever wondered how some companies release new things just after they've announced them at a live conference? Well, with feature flags, that's possible---they just toggle a switch and enable the new feature. From the moment you start coding, you can wrap the new changes into a conditional block and deploy anytime you want, but with the new code disabled. Thinking of introducing the new change in secret, also known as a dark launch? No problem---just make sure all your tests are passing with and without the new code. It doesn't matter really which deployment strategy you choose. Whether it's blue/green (B/G) or canary deployment, feature flags fit perfectly. Let's talk about a B/G scenario in which you have the green version running and the blue version as a candidate to be released. The blue version will have the feature turned off. Blue and green versions will run together for some time. And then you turn on the new feature. If something goes wrong, instead of switching back to the green version (because fixing things could take some time), you can just turn off the new feature immediately. Taking this approach, you'll know for sure which version has problems, and that will lead to reduced downtime. The same thing goes for canary releases, only the benefit here is more evident. Imagine you encounter problems when almost finishing the rolling update. Normally, you'd have to roll back. With feature flags, you don't have to worry about that. You just turn the feature off. Feature flags enable your apps to be backward compatible, and that's critical for deployments with less hassle.

Most of us have seen the movie The Matrix. What pill would you choose, if you had Morpheus asking you? Red pill for the truth of reality? Or would you pick the blue pill and continue to believe an illusion? What if you wanted to try both and then choose? Unfortunately, that wasn't possible in the movie, but in software, with feature flags, it's possible. Facebook, Netflix, and other companies claim that they run experiments all the time. In fact, this is how Amazon launched their recommendations section you see on each product page. A developer had the idea of making recommendations to customers by showing what others had bought when shopping for the same product. They ran the experiment for a while, showing this section to some users and tracking the results, using the A/B testing technique. We all know how it ended because now everyone sees that section. But you don't need to be Amazon to run A/B experiments. Let's pretend we're working for Amazon and we need to run the experiment I just mentioned. We'd add the code for a feature flag and decide which percentage of users, with the criteria we define, will see the new feature. Then, we'll collect metrics to see how many more purchases came from those who saw the "customers who bought" feature versus those that didn't see it. If the new version proved to be more profitable, we'll just change the feature flag value to make it available to the rest of users and keep monitoring. The great thing about this is if for some reason we decide we don't want the feature anymore, we don't have to redeploy; we just need to turn the feature off.

There have been times when I wish I'd enabled the verbose logging in my code---especially when I receive reports that some users have been experiencing errors in code. The first thing I do is try to reproduce the error. If I'm lucky enough and succeed, the next step is to see logs. The sad part of the story is that, at this step, there's nothing more than "something unexpected happened here." It's understandable if you don't want to have verbose logging because disks could run out of space. No one wants to be awakened in the middle of the night with this news. But what if you could launch your code with verbose logging turned off and only enabled when you need it? Yes, with feature flags, it's possible. You could activate all different types of logging that you previously configured but released them deactivated. Everyone will be happy with this approach: you get the information only when you need it, and no one has to worry about being paged about a low space problem or purchasing more space just to avoid it.

You don't need to worry about integrating unfinished code with the rest of the team when using feature flags. A common approach is to use feature branches when working on a new change. The problem with this approach is the dreaded "merge conflict hell"---you know, that moment when you're trying to merge your feature branch to controller. The moment you'll do anything to avoid. Some clever folks might even distract other developers so that they can merge their branch first and avoid this pain. It would be funny if it weren't true. The idea with this, number four in our list of feature flag use cases, is to minimize problems that will steal valuable time from the team. When you code something you know for sure will take more than the rest of your day, you'll see the benefit of feature flags. That's because you can always push your code with the feature toggled off. Merge conflicts will be reduced, and it will be much easier and cheaper to fix them because everyone is pushing their changes more frequently. You might be afraid of pushing your changes to controller; something incomplete could go live or the build could fail. But if that happens, other team members will look at the code to identify which flag was recently turned on. Then, they can simply turn it off and continue working. You'll realize there's no need for this fear any longer, thanks to feature flags.

Have you ever seen a message in a system saying they're testing a new layout and asking you to opt into the new interface? I have. And in my experience, if I don't like it, I can just simply opt out. Feature flags can be at the user level too. If users were selected to test a new feature, they could always just turn the new feature off if it didn't suit them. Feature flags can also help you enable certain things for premium users. How easy would it be to upgrade a user? Quite easy. Just turn the premium features on for that user, and you're done. At some point, your app might have a ton of features that your experienced users love. Just remember that you always have to think about your new users, too. They could get confused and stop using your app because they don't even know where to start. A good solution for this is to turn off non-common features. Learn little by little how they're using your app, and suggest features to them from time to time. Simplicity is the key. Try to avoid giving the impression that your app is hard to use or hard to learn.

This is how a few more lines in your code can let you experiment more. You'll also enjoy the peace of mind that comes with just being able to turn things off when the result isn't what you expected. When you plan ahead and write your code intentionally, good things emerge from it. Everyone's productivity will increase because it's not just developers that will be able to push unfinished code; also, the operations team will be able to roll back easily when it's needed. Even if I was able to convince you where and how to use feature flags, until you start practicing using them, all of the above will be just theory. And one last thing---you can use feature flags almost everywhere, and you can use them many times, but eventually, they'll need to get retired. But meanwhile, apply the advice in the feature flag use cases listed here, and enjoy watching your stress levels decrease!