A toggle is a small piece of hardware, like the key on your keyboard that switches between caps lock and num lock, or a software feature that lets you switch between two different screens while video chatting with friends. It’s a switch that allows you to toggle between two opposing states, and the best design for them leverages clear visual cues and direct labels so users can quickly see what each state does.
The most important thing to remember about using toggles is that the decision to use them is often a tradeoff. The ability to rapidly experiment with new features is often a tradeoff against the overhead of managing and monitoring the configuration for those toggles. For this reason, savvy teams always weigh the cost and impact of a feature before adding a toggle to the codebase.
One important point to note is that if you choose to use toggles it’s best to test your product with them flipped on. This is because a toggle that isn’t flipped on will often hide existing or legacy behavior, and you’ll want to be sure that any new behavior is properly enabled before rolling it out to the rest of your user base.
A number of approaches exist for managing toggle configuration, ranging from static files to dynamic in-memory re-configuration. For the former, some teams use commenting or the preprocessor’s #ifdef feature, but this is typically only suitable for Release Toggles that will stay around for a short period of time (although this approach can be useful for testing purposes). More sophisticated approaches involve storing toggle configuration in an application DB or leveraging existing infrastructure to manage these changes.
