Feature Flipper (Or Toggle): What Is It and Why Use It?

The following is a guest blog post written by Marjan Venema.

You hit the button to confirm the last merge pull request for the day and slowly lean back in your chair. This is it. Tomorrow the new release hits every customer. Everybody on the development team has done their utmost to make it good, but you still feel the weight of uncertainty like a rock in your stomach.

You wish there was a way to avoid these big-bang releases. They’re nerve-wracking and usually mean at least two weeks of interrupted sleep as customers find the glitches you and everybody that tested the release didn’t catch.

You’ve heard feature flippers are the way to avoid the nerves and the pressure of fixing bugs in production. Your developer friends rave about them, but you just haven’t had the time yet to look into them.

Well, reading this post will only take a few minutes and will tell you what you need to know. So just relax for a moment and read on.

You’ll learn exactly what a feature flipper is, what it is that’ll turn you into a raving fan, and what a good toggle management system helps you do.

In its simplest form, a feature flipper is a conditional statement that controls whether the code for a specific feature will be executed.

if (FANTASTIC_FEATURE === true && SOMETHING_ELSE > THRESHOLD)

{

// execute new code

}

else

{

// execute old code

}

Feature flippers are also known as feature toggles, feature flags, and feature bits. They all serve the same purpose and are used interchangeably.

When you start using feature toggles, it’s good to be aware of some terminology.

• A toggle point is a point where code execution branches in one direction or the other: the conditional statement in the code above.

• A toggle router is a function that decides whether a feature is enabled or disabled. Unlike the example above, you want to use toggle routers at your toggle points because you want the decision logic in a single place.

• When the values a toggle router used to make its decision come from outside, you use toggle configuration. For example, a configuration file or a system setting or an environment variable.

• When the data used by a toggle router is specific to a group of users or even a single request, that data is your toggle context.

Maybe you are already dreaming of how using feature toggles will make your life easier. And maybe you get what they are and how they work but don’t quite see why you’d want to go to the trouble of using them.

So let’s explore which problems can be solved using feature flippers. And perhaps more interestingly, what they make possible.

Using feature flippers, you can say goodbye to feature branch merge hell because you no longer need feature branches. Everyone can work on the controller (trunk-based development) and not be in each other’s way because defaulting feature toggles to disabled means no feature’s code is active when it shouldn’t be.

Your new feature’s code has no impact unless its feature toggle is enabled. So you can safely commit before it’s ready for use by others, even to the trunk. Committing small changes often also gets you the benefits of a shortened feedback loop.

The trunk-based development enabled by feature flags means the trunk is always in a releasable state. That means you can have continuous integration, delivery, and deployment to production. And that, in turn, means that releasing code and releasing features are no longer joined at the hip and you get to test in production.

You can use toggle configuration and toggle context to be selective about which customers get to use a new feature. This allows you to see how a feature is received and is holding up before rolling it out further.

With a canary release, you randomly select a percentage of users. It’s perfect if you want to monitor performance issues and unforeseen glitches. With a champagne brunch, you select specific people. It is perfect to dogfood your own app to get early feedback from internal users (alpha testing), as well as to run large opt-in beta tests.

Feature flags are great for experimentation. You can create different simple implementations for an idea to work out which performs or is received best. Also, you can create simple implementations for several ideas to see if and how they are used and work out which of them to build out first.

Using feature flags to run A/B testing experiments means you no longer have to guess. Because you now use trunk-based development and test in production, you get to gather data from real live users and get to make data-driven decisions. That data will go a long way to change any HiPPO (highest paid person’s opinion) in the room.

Without feedback from real live users, you’re never sure how they’d like new features to work, or what they’d find easy or cumbersome. So you try to perfect it by making it do everything for everybody.

Feature flags allow you to deliver the smallest thing that can deliver value into the hands of real live users and get their feedback. Feedback you can use to update and improve. Continuously.

This will do wonders for your development speed. Not just by keeping changes small and really incremental, but especially by not spending any effort on what users won’t use anyway.

Sometimes, despite your best development and test efforts, releasing a feature to your customers has a big negative impact. Wouldn’t you like something as easy as flipping a switch to kill that feature? Feature toggles make perfect kill switches!

Feature flags enable marketers and salespeople to entice people to pay more for access to more features.

Kill switches can be used when your systems experience an unusually high load. Disabling features that are expensive in terms of resources and performance can allow your app to continue its essential function.

By now you may think that feature toggles sound too good to be true and there must be a catch. And you’d be right. Feature flags have a few pitfalls you want to avoid.

Using feature toggles increases the complexity of your code, and for each toggle, you need to run your tests twice: once with the toggle disabled and once enabled. However, it’s not as bad as it sounds. Feature flags rarely influence each other, so you don’t have to test every possible combination. And if you release features often, each release will only touch a limited number of feature flags.

You will have to restart or even redeploy to test environments when you can’t change your toggle configuration at run-time. This increases test time, and that negatively affects the CI/CD feedback loop, which in turn has an adverse effect on developer effectiveness and development speed.

Feature toggles tend to multiply like there’s no tomorrow. If you let it get out of control, you’ll end up with a tangled mess of conditional logic that’ll be hard to decipher. Your code will become harder to reason about and more difficult to maintain, slowing down development more and more.

The advantages of feature flippers far outweigh the drawbacks. Plus, you can easily mitigate these by being proactive in keeping your feature toggles under control. Proactively removing toggles that are no longer necessary, for example.

Still, to get the full benefits of feature toggles, you need a good system to manage them. Not only to keep track of them, but also to:

• Manage who can change a feature toggle’s state. For example, allowing marketing and salespeople to determine which (types of) customers get to use a feature. Or allowing product managers to play with toggles for A/B testing.

• Give operations people control of the kill switches they need to keep your app running with limited features, rather than it crashing altogether.

• Offer a good, simple user interface that non-techies can safely use.

• Integrate with your CI/CD server.

Of course, you can build and grow your own toggle management system. At first, that will seem like the obvious thing to do. Soon, however, working on it will be taking precious time and effort away from the product you want to and should be working on: the product your customers pay for.

That’s why it makes total sense to take advantage of a product that’s someone else’s core business, so you can concentrate on yours.

Celebrate. You made it down here. And that means you can start to calm your nerves and sleep easier. You now know what you need in order to no longer dread a new release.

So what’s next?

Well, I’d recommend reading about some best practices and then getting your hands dirty. There is nothing like practice and execution to really get the power of what you’ve learned.

An approach I’ve found that works well is to start a small, even tiny, project and use feature flippers with everything you’d do for a real live project: create new features, fix bugs, try a canary release, do some A/B testing, and take a champagne brunch.

While you’re at it, take CloudBees’ feature flag management system for a spin. By doing both, you’ll get a much better sense of what’s involved in growing your own and everything you gain by adopting a solution by a company that makes it their core business.

Marjan Venema is a Smart Blogger certified content marketer, working from the Netherlands with over 30 years of experience in software requirements, analysis, development, and support for the Business Planning and Analytics, Financial and Manufacturing industries. Her specialty is writing comprehensive engaging content that makes complicated and complex topics easy to understand and consume. She writes straightforward language in a conversational style and illustrates abstract topics with concrete examples.