The word toggle is used to describe a switch that can only be in one of two positions, on or off. The same can be said for software features that can only be enabled or disabled. For example, the caps lock or num lock buttons on a keyboard are toggles as they only allow the user to switch between two functions on the machine. A more common use is found in a options menu in an application where the user can toggle between different options.

A toggle can also be a part of a larger product feature that may be enabled or disabled for a cohort of users. This is often known as a Canary Release or Champagne Brunch feature and is commonly used in a testing environment to make data-driven changes for a subset of the existing user base.

Toggle configuration can be hardcoded into code via static files or a preprocessor’s #ifdef feature. However, this approach is only really suitable for toggles that have a short lifespan and will not need to be dynamically re-configured on a regular basis. A better solution is to move the toggle configuration into some type of centralized repository which can be accessed by developers, testers and product owners through an admin UI.

As a rule of thumb, it is good practice to test the toggle configuration that will ultimately become live in production. This includes testing with all the toggles flipped Off as well as testing with every toggle flipped On. For longer-lived features, it is also wise to add a task to the team backlog to remove the toggle as it is no longer required.