Toggle (also toggle switch) is a term used to describe any kind of control that can be set in one state, and then switched to another. They are common across user interfaces, particularly in software when setting options and preferences. Toggle switches are most effective when they have direct labels, are clearly distinguished from other controls through visual cues like movement and color, and are easily understood by the end user.
Historically this was done through comments in the code but this approach can be cumbersome as you scale up. It also requires a disciplined process of continuously updating the files to maintain up-to-date configuration, which in turn can impact the cycle time and feedback loop of your development environment. For this reason a better option is to move your toggle configuration into some type of centralized store, usually an existing application DB. Combined with some form of admin UI this allows system operators, testers and product managers to view and modify feature flags and their configuration.
For high-volume production environments the ability to dynamically re-configure a toggle at runtime can make all the difference in terms of testability and speeding up your validation processes. This becomes particularly important for categories of Toggle such as Champagne Brunch and Experiment Toggles where the toggling decision is made at each runtime for a cohort of users rather than per-release.
Savvy teams consider their inventory of feature toggles to have a carrying cost and try to keep that cost as low as possible. They do this by proactively adding a task to their backlogs to remove a Toggle as soon as it’s no longer needed, and creating “expiration dates” on their Toggles that will cause tests to fail at runtime if they aren’t removed in time.