Sometimes referred to as feature toggles, feature flippers, or feature flags, these terms all represent the same idea. We’re just talking about the ability to turn things on and off. While this seems simple, it can be quite liberating when a team starts using this approach to reduce the friction of adding new features to existing code.
In some cases, feature toggles are as simple as using a conditional (if-then-else) statement. We always had the ability to alter the flow of a program using conditionals, but the value behind feature toggles is that we are optionally enabling a new path in the code. This new path creates a logical isolation that allows us to try out new features with minimal risk because we’re leaving the existing code intact. This is powerful because having control over features gives us the ability to:
Implement big changes without blocking the changes we need to make today.
Safely test and learn in production by controlling the availability of features.
Roll back a feature by turning it off instead of doing a deployment.
At Credera we implemented this approach for the website of a national restaurant. This company recently updated their customer loyalty rewards program, but the part that’s less obvious is that the supporting code was running in production months before those features were enabled. While we were refining how the site would look and how the code would ultimately change to support this new program, we needed to support bug fixes, update the FAQ page, and add small features to the site. We needed the ability to make any change we wanted whenever we wanted; we couldn’t stand still while we waited for this big change to go live.
how did teams implement big changes “back in the day”?
This would have been a scenario where the development team would create a new branch of the codebase to support the initiative of implementing a new loyalty rewards program. This approach is known as the “Development Isolation” branching strategy.
Creating this split in the codebase gave developers the freedom to make big changes, but what people usually don’t discuss is that the longer the two branches live, the farther they drift apart. Drift is the concept of our isolated codebase (the feature branch) not incorporating new changes. As planned, the feature branch is isolated, so changes made to the TRUNK branch do not affect the feature branch and vice versa. To correct the drift, teams had to perform reverse integrations and forward integrations to keep the two branches in sync.
There are two big problems with the Development Isolation strategy:
The process itself is generating new maintenance work in the form of reverse integrations and forward integrations. Unfortunately, developers can’t reduce this pain by reducing the frequency of these integrations. That usually makes the merges between the two branches more complicated as the branches will have even more differences that must be kept in sync.
The process introduces the risk of new defects due to incorrect merges. Branches like these were often created to implement changes that touch a lot of files or because a change touches a critical/fast-moving system. So conflicting changes became inevitable and merges became something the lead developer would do so the team could mitigate the risk.
feature toggles to the rescue
Because feature toggles provide a logical isolation of new code from the original code, we can now support our big changes, like the loyalty rewards program, without blocking the changes we need to implement today.
We used a feature toggle to turn the features on and off at will. A configuration file provided the default behavior, and an admin page provided the ability to override the setting. When we wanted to test the new features in a QA environment we would deploy a build with that flag enabled. When we wanted to disable them and work on a quick change, we turned it off so that we could make the changes we wanted to make today and release without waiting for the new loyalty rewards program.
My favorite part of this approach is the confidence this gave us that things would behave as we intended when we were ready to share them with the world because we were able to test in production. We didn’t have to wait until the night of the go-live to see if our configurations were correct or if the networking was set up correctly. We knew it would work because we had already tried it. Better still, if we had been surprised, we could toggle the feature off without redeploying the site.
some food for thought in closing
If you could wave a magic wand over the application you’re using today, what would you change? When you hear things like:
We can’t change that. The amount of training would be overbearing.
We can’t change that. The contract for Company A says it has to be that way.
We can’t change that. We don’t know how it would impact other systems.
Maybe you should consider a feature toggle to reduce the friction of change. With a feature toggle, you can:
Target a subset of the application’s userbase and use a train-the-trainers approach.
Create features that go live based on key business dates like the end of a contract.
Limit access to features in production to a focus group and see how they behave in your production environment.
Successful businesses innovate, and you can’t innovate if you can’t make changes.