Toggle is a powerful tool to have at your disposal when building software. Its ability to dynamically re-configure specific service instances is incredibly useful. But it’s also a sharp knife and can create pain, confusion and chaos if used improperly. Toggle is most effective when used to support dev teams during development and experimentation, rather than being used as a way to make large-scale changes to the live production codebase.

A toggle is a switch that has two positions – on and off. We use toggles all the time when we video chat with two friends at the same time, or use the mouse keyboard shortcut Alt+Tab to swap between windows and programs on our computer.

Toggles can be applied to any object or interface element. They can be as simple as a button with an on or off label, or as complex as a decision tree which takes into account multiple different conditions. The conditional logic behind a toggle can be anything from the results of a fitness test, a setting in the feature management software, a variable provided by a config file or a set of heuristics such as user location and context.

As a design principle we try to avoid toggling too many features at the same time. This is for the sake of keeping our code maintainable, and making sure that a change does not impact other teams who are still working on projects. If a toggle covers too much of the product, it can become confusing for users and a nightmare to debug weeks or months down the road as other teams continue to work on their projects.

When a team is ready to release a toggle it is important that they test all the possible configurations. This means testing the toggle with its expected live state (which would be flipped On) as well as the fallback configuration of all those toggles that will be flipped Off. Many teams also perform some tests with all toggles flipped On, to ensure that future changes won’t break existing functionality.

Another important thing to consider when designing toggles is that they must be accessible. We often rely on visual cues to convey the state of a toggle, such as the color red for “on” and green for “off”. But this can be misleading to some users, especially those with color vision deficiencies. Fortunately there are tools available that can help us check that our toggles are accessible before we go live with them.

Toggle configuration lives side-by-side in source control with the code that it affects. This makes it easy to track changes, roll back to previous releases and see how the toggle has changed over time. This allows the team to have a complete picture of what is going live, and gives them confidence that they won’t be surprised by unexpected regressions when they make the toggle live. This is why Toggle is such a valuable tool for modern software developers.