A toggle is a pin-like fastener that’s either pushed through a loop or hole to hold something fast, or turned through a lever or handle to switch two functions. In the case of a computer, it’s what you push to turn your caps lock on and off. Toggle can also refer to software switches that enable you to swap between different options, like the ones in a video chat application that allow you to toggle between screens during a conversation. The word can also be used figuratively as a verb: “to switch between two things,” like when you toggle between the stream view and map view of a live video game.
Feature Toggles are great for allowing teams to experiment with features without risking the impact on existing or future users. They also encourage a culture of experimentation where ideas for improvement don’t just come from the product team but also from engineers who feel less constrained by “I don’t think that will work” and more motivated to try it out.
When a toggle is rolled out to production there is typically no need to test it with both the toggle On and Off states, as the decision to go live with the toggle flipped on has already been made and can’t be changed (for more dynamic flags at least). Likewise, because the toggle configuration lives side-by-side in source control, rolling out a new release with a change to the toggle is easy and quick.
However, savvy teams are aware that a feature toggle has a carrying cost — in other words it takes up space in the codebase. Therefore, a number of teams have rules in place to be proactive in removing toggles when they are no longer needed. Some teams have a policy of adding a toggle removal task to the backlog whenever a new toggle is introduced while others put expiration dates on their toggles which will fail a test (or even refuse to start an app!) if the toggle is still around after its intended expiration.
For the more dynamic categories of Feature Toggles – such as Champagne Brunch or Permissions Toggle – it’s usually important that you have a way for your testing infrastructure to automatically re-configure a service instance to enable or disable specific toggles at runtime. This is to avoid the need for manually restarting a process and disrupting your testing environment. For example, many CI/CD systems will have a snippet of code which can be used to override the default config for a given service instance by specifying the path where it should look for the config file. In these cases the ability to re-configure a running service is called a Toggle Override. This is a very powerful tool but can be dangerous in the hands of an engineer who doesn’t understand how to use it properly. For these reasons it’s very important that you have a system for Toggle Overrides in place and that all engineers are trained to use it.
