A toggle is a switch that can be used to activate or deactivate features on a device. In software, toggles are often used to allow users to change settings or preferences (e.g., the option to turn on or off Airplane Mode). They are also a preferred alternative to radio buttons when working with mobile devices due to their smaller form factor and the fact that they require a single tap to apply changes.

Savvy teams view the inventory of Feature Toggles as carrying costs and seek to keep their count low. To help manage this inventory some teams will add a task on the backlog to remove toggles after they have been flipped Off and some even put “expiration dates” on their toggles such that they won’t work anymore after a certain date.

Using toggles for configuration can be tricky once you get to a certain scale because changing the state of a toggle may require modifying the corresponding static file on every server. This can have a significant impact on the cycle time of your validation process and the all important feedback loop provided by CI/CD. To address this challenge many teams use a runtime toggle configuration system where they enable/disable features at runtime instead of via static files.

When using a runtime toggle configuration system it is best to test all possible toggle configurations that you might want to release into production. Often this will include testing a toggle with all its flips OFF as well as the fall-back configuration where existing or legacy behavior is enabled and new or future behavior is flipped ON. This helps ensure that no regressions are introduced by accidentally enabling a toggle that was previously OFF when you flipped it On.