The 18th century definition of toggle referred to “a pin passed through the eye or bight of a rope to fasten it.” Today, the word is used as a metaphor for a switch which can be turned on or off.
In software development, toggles are a type of feature flag which can be flipped at runtime to enable or disable a codepath. This allows teams to make data-driven improvements to the user experience without the need for a significant codebase refactor or the delay of having to redeploy and restart a test run.
While a toggle configuration can be hardcoded in static files there is often a preference for a more dynamic approach which allows for at runtime re-configuration of specific service instances. This can range from simple solutions such as commenting in the code through to some sophisticated approaches which may require a refactor of the core application to implement.
Savvy teams try to be proactive in removing toggles that have been deployed and are no longer needed. This helps to keep the inventory of toggles under control and avoids unnecessary maintenance in future releases. This is especially important for Canary Releases or Champagne Brunches which are more likely to have longer lifespans than other categories of Feature Toggles. For this reason many of these types of toggles are also given an expiration date in the form of a time bomb which will fail a test (or even refuse to start an application!) if the toggle is not removed by an explicit deadline.