A toggle is a switch that has two states — On or Off. It can be found in a variety of software applications such as a browser extension or in physical switches such as the ones used on a video chat screen to toggle between two screens. It’s also commonly used as a metaphor for a transition between state.
Toggle switches are often confused with checkboxes. While they may have similar appearances (and use the same markup), the use of toggles requires special attention to accessibility and usability because unlike a checkbox which can have an indeterminate value a toggle only has two outcomes. For this reason, it’s best to only use toggle switches when they are truly a switch between two opposing states.
Generally speaking, most toggles should be short-lived although it is possible for some product-centric toggles to live longer. For example, a Champagne Brunch feature might need to stay in place for a few weeks or more, but is usually not expected to be in a permanent state like a Permissioning Flag.
It’s important for teams to be proactive in removing toggles that are no longer needed. Savvy teams make a point to add a task to the backlog to remove a toggle when it’s first introduced and to regularly look for opportunities to eliminate toggles. Some teams even put “expiration dates” on their toggles and will have a process in place to fail a test or refuse to start an application if it’s attempting to access an expired toggle.
Many of the same considerations that go into a proper toggle implementation apply to other configuration options as well. For instance, a common practice is to move away from static file management of toggle configuration and into some form of centralized repository such as an existing application DB. This allows for dynamic in-memory re-configuration of a toggle and can speed up the CI/CD cycle of your validation testing and ensure consistency across your fleet of servers.
Another factor to consider is that toggles often come with a cost of carrying inventory so it’s important for teams to be diligent in managing and limiting the number of toggles they have. This is especially true for those teams that use toggles to perform A/B or multivariate tests where each user will be sent down one codepath or the other based on their cohort status.
A savvy approach to this is to always have some test code that exercises both paths of a feature and to also have some tests with all toggles flipped on (i.e. the current production toggle configuration). This can help prevent regressions in future releases and provide a safe fallback for any new or changing behavior that a team is adding to their product. The latter can be accomplished by exposing an endpoint to allow for dynamic in-memory re-configuration at runtime. This is a powerful feature that gives a lot of flexibility and power to the entire team while at the same time allowing for a more efficient testing and validation process.
