Toggle is a small piece of wood or plastic which is sewn to something such as a coat or bag, and pushed through a loop or hole to fasten it. On computers and some other machines a toggle can be used to switch between functions, for example, to turn the sound on and off.

A toggle is also a device for controlling a power outlet, for example, on the back of a laptop or a mobile phone. Toggle switches are often used for safety reasons as they can cut power when pressed in the wrong way. The word toggle is also a verb, meaning to bind something temporarily with a toggle; for instance, you might toggle the com to talk to air traffic control, or you might toggle between two screens while video chatting with friends.

The term toggle is a short-lived feature flag, and as such, savvy teams try to minimize the number of toggles in their codebase. They view them as inventory which comes with a carrying cost and seek to make the inventory as lean as possible. In addition to making sure the toggles are properly tagged and tracked (a process known as Toggle Coding) most teams have some kind of policy in place which ensures that they remove any unused toggles from their codebase. This is done by adding a task on the team’s backlog whenever a new release with an existing toggle gets rolled out. Some teams even put “expiration dates” on their toggles, ensuring that they get removed before the feature becomes obsolete.

Managing Toggle Configuration

As you scale up your use of feature flags it becomes increasingly important to manage the configuration of these toggles in some kind of centralized fashion. Using static files is fine at a certain point, but when the quantity of toggles increases it becomes inefficient to modify these static files manually. This is especially true in environments which require a complex pattern of re-deploying an artifact to test and verify a feature flag.

To this end many organizations move the configuration of their feature flags into some sort of centralized store, typically an application DB. This usually accompanies the build-out of some form of admin UI that allows for system operators, testers and product managers to view and manipulate these flags.

When it comes to testing these kinds of toggles many teams have a practice of performing some tests with the toggles flipped Off and some with them flipped On. This helps them to avoid any surprise regressions in a future release by ensuring that they are able to see both paths through the feature.