A toggle is a switch that allows users to switch back and forth between settings or modes. We can toggle between video chat and text while chatting with a friend at the same time, or toggle between the stream and map views of our favorite streaming service. Toggle also refers to the ability to shift between multiple browser tabs and windows on a desktop computer, or the choice of whether to toggle between the baseball game and the news while watching TV.
Feature toggles are also known as “feature flags” or simply as “flags” and they allow a team to manage the state of a new feature without redeploying code to production every time a change is made. This can be a very powerful tool for dev teams that need to experiment with new features in the wild but still deliver value to their customers with existing releases.
When a developer decides that a new feature is too resource-intensive or risky to roll out as an entire product, they can create a toggle in the master branch and generate a release build with that toggle flipped off. They can then test the feature without deploying it to production and re-test it with the toggle flipped on once they’ve finished coding.
The best practice when designing a toggle is to always have a clear label that describes what the switch will do if it is on and what it will do if it is off. This way a developer knows what they’re going to be testing and their testers can compare results with the expected outcomes. If the toggle is not clearly labeled a user might misunderstand what it does and might unintentionally enable behavior that they don’t want.
Another important consideration is that a toggle should only allow one or the other of two states to be enabled at any given time. If there are more than two possible states, a checkbox or other form field is better suited for the task. Finally, a toggle should not be used to control downloads or other one-time events because it’s difficult for a user to understand the difference between an on/off toggle and a download button that just downloads something once and then never downloads again.
Savvy teams view their feature toggle inventory as an asset that has a carrying cost and strive to keep it low by removing toggles when they are no longer needed. They may do this by adding a task to the backlog or they may put an expiration date on a toggle that will cause a test to fail if it is still around after that date.
A less sophisticated but more reliable approach is to hardcode a toggle in your code, using a preprocessor’s #ifdef feature or a conditional statement in a programming language. However, this type of configuration is only suitable for toggles that don’t require dynamic re-configuration or for cases where we are willing to follow a pattern of re-deploying in order to flip a toggle.
