The word toggle means a switch that has two settings, on or off. It’s a simple concept that’s used in everyday technology, like the caps lock and num lock keys on your keyboard, or on an options menu in most software applications. It’s also a key component of many newer agile development methodologies, which enable teams to release features that aren’t complete yet. They can be hidden behind toggles until they’re ready to go through a user or market test, and then they can be merged into trunk code.

One best practice is to always name a toggle with an explicit description of its purpose and its scope. That way, any team member looking at a feature flag can quickly understand what it does and how it works—even if they haven’t seen that particular toggle before. This gives some useful context to the person working with that toggle, which is especially important if they’re not familiar with the product and its history.

Finally, savvy teams try to keep the number of feature toggles under their control as small as possible. They view them as inventory with a carrying cost, and they want to minimize the risk of releasing a toggle configuration that doesn’t work as expected. In order to avoid this, they often test their releases with every toggle flipped On (or the fallback configuration) and then only with a subset of them flipped Off.

In addition, some teams take it a step further and put “expiration dates” on their toggles—which will fail a test or even refuse to start an application if they’re not removed by a specific date. This prevents a rogue toggle from hanging around and impacting future releases or causing bugs down the line.