A toggle is a switch that has two positions, like the on/off button on your keyboard or the light switches in your house. You can also use the word to describe switching between two activities, like the way you toggle back and forth between screens as you video chat with two friends at once.

The word toggle is a combination of two Latin phrases, to bind and to turn. In 18th century Britain it was used to refer to a pin passed transversely through an eye or loop in a chain, or a rope, so that it could be temporarily fastened to another such pin and thus turned on or off. Today it is still often used for this kind of temporary splicing. It is also a name for the kind of joint that you can fasten by passing a rod through an eye or loop, or for the knob-like button that holds down the ends of a cord or drawstring to stop it from moving.

In software development, a toggle (also called a feature flag) is a switch that can be flipped on or off, and which determines the behavior of a program. Typically, it is set to an off position by default and can be turned on by a developer or product owner.

A common approach to implementing a toggle is to hardcode it in code using a preprocessor’s #ifdef feature. However, this is a cumbersome approach once you start to scale because it requires that you re-deploy a code artifact in order to change the toggle configuration. This slows down validation and creates a significant bottleneck in the feedback loop that is so vital to CI/CD.

For this reason, many teams choose to implement a toggle system that allows them to dynamically re-configure the state of a toggle at runtime, without having to re-deploy a change. This may be as simple as exposing an endpoint that allows for in-memory re-configuration of a toggle, or it might involve more sophisticated approaches such as a distributed configuration system or existing application DB. Whatever the approach, it is generally best to keep toggles in production as short-lived as possible. Savvy teams tend to view them as inventory that comes with a carrying cost and seek to remove them once they’re no longer needed. Some even go as far as putting “expiration dates” on their toggles. This helps them manage their feature flag inventory and prevents unused features from lingering in production too long.