Toggle is a simple user interface control that delivers immediate results without the need for users to hit Save or Submit. It’s used by software to enable or disable functions. It’s also used in hardware to switch on and off specific functions. For example, keyboards have toggle switches that turn on Caps Lock and Num Lock. Toggle is a powerful tool but it must be wielded with care. It should be used only when it makes sense to do so, in a manner that’s consistent with the context and provides clear user feedback. Toggle can be used to enable new functionality that will eventually replace existing functionality or to provide a safe fallback. For example, if you want to test a new feature in production you should ensure that all existing toggles are flipped Off and the new feature is flipped On. It’s important to do this as it will prevent you from releasing a regression and helps to avoid confusion for your users.
Savvy teams view Feature Toggles as inventory that comes with a carrying cost and they seek to keep their toggle inventory low. As a result, they are proactive about adding tasks to their backlog to remove toggles once they’re no longer needed. Some teams even use “expiration dates” on their toggles to force themselves to be proactive about removing them from their system.
Toggle configuration can be managed in a variety of ways ranging from static files that are hardcoded using a preprocessor’s #ifdef feature through to complex distributed config systems. The most effective approach is to use a real toggle-specific config system that enables you to re-configure the toggle in runtime. This avoids having to re-deploy a code artifact just to change the toggle and it’s particularly important for Ops Toggles and Champagne Brunch features that are short lived.