Toggle. The word has its origins in 18th-century British seafaring. A “toggle” was a pin passed through the eye of a rope or strap to hold it in place. Because of this, it came to mean to fasten and unfasten something or to turn it on and off, which is why computer scientists in the 20th century started to use it to reference a key that could turn any function or feature on and off.
The Feature Toggle was thus born.
Understanding Feature Toggles: What They Are and Why They Matter
By providing a Feature Toggle in software, one has an alternative to using different feature branches in the source code. This “toggle” in the code allows you to turn a feature on and off while the software runs. A feature toggle can also be used to enhance a user’s experience. All you have to do is turn the Feature Toggle on or off, and the feature will either be available or won’t. This can allow you to personalize your experience, but if you are testing different features, it gives you more flexibility.
Feature Toggles vs. Branching Strategies
But wait? How do I know all of this? Well, I have more than two decades of experience as a developer. For seven years, I was the lead application developer at Thoughtworks, at Atlanta, Georgia-based technology consultancy that offers custom software development. You could say it was here that I became a Feature Toggle enthusiast.
Only some people are fans of Feature Toggles. They believe that branching is a cleaner approach that doesn’t litter the code with Toggle codes that they feel are unnecessary (because it only gives you operational benefits). Branching has been the conventional strategy to manage features not yet ready for primetime. Feature Toggles also have their upsides.
Key Considerations and Best Practices
Before we go any further, we should flesh out a branching strategy and a feature toggle strategy. In Branching, separate “branches” are maintained for each feature. When the feature is ready for use, these get attached to the main line. After another round of testing, the feature can be rolled out as part of the software.
With a Feature Toggle, the code allows you to turn the feature on or off. That means you can use it or not, and it won’t impact the overall functionality. Once a feature is ready to go, all the developer must do is turn the Feature Toggle on and Voila. It’s ready.
As with everything in technology, there is a time and place for implementing both strategies. Branching makes sense if you make significant changes, such as upgrading external package dependencies. This can get difficult, though, if you have a big team, with many different developers tinkering with the code. All of those developers with their branches might cross, creating unnecessary headaches down the road. You can’t try out other features by shutting them on or off one at a time, as you can if you opt for Feature Toggles.
Types of Feature Toggles: Exploring Feature and Business Toggles
However, a Feature Toggle strategy also has its downsides. For example, you will need an operational process to remove the toggles after they are enabled, and you’ll have to coordinate with your engineering team to ensure they are maintained across all code environments.
There are also different kinds of toggles, such as feature and business. As noted, with a Feature Toggle, you can continuously deliver your software while integrating and trialing unfinished features into the release pipeline. Feature Toggles have to go through the regular development cycle of testing before deployment.
A Business Toggle is similar, except that it can be turned on or off due to customer feedback or if someone is doing A/B testing of a product. Of course, you have to be sure that the Business Toggle will not interfere with the software’s operationality, no matter if it is on or off.
Only some people are Toggle experts, but there are different options for those interested in adopting this approach. You could build your own, for starters, or opt to buy in. Feature Toggles are available from www.flagsmith.com. These are great tools that I have used myself in various startups, and they can be used on multiple platforms.
Now, to get to the excellent stuff: my advice on Feature Toggle Development. First, every feature needs a first commit that will initially set up the Toggle. You also have to make sure that different environments are suitable for toggles. Also, don’t let your confidence get to you! Nested Toggles are nice, but you can address the issue via another route. You must also test the code to see whether the Feature Toggle is switched on or off. Once you implement Feature Toggles, you will need a dashboard to see which ones are live.
I also use Dependency Injection Patterns in my work. This allows you to avoid cluttering up the code with Toggle logic and manage your different Feature Toggle implementations. It also allows you to test out both sides of the code before implementation.
Overall, Feature Toggles provide developers with advantages in some cases over conventional methods and should be viewed as a potential solution by all innovators.
