A toggle is a switch that has two positions, on and off. We use toggles to turn things on and off in technology devices like phones and laptops. We also use toggles in software applications to enable and disable features. For example you can toggle between stream and map views in an exhibit or the camera view in a photo app. We can also toggle the privacy settings of a website.

Feature Toggles allow us to make changes in the code that affect only some users of an application at any given time. This allows new features to be released without having to go through the lengthy testing and QA process that they would have under traditional waterfall development models. The advantage of this approach is that all of the testing and QA work is done on trunk code and the new features are hidden behind toggles until they are ready for release.

Savvy teams treat their inventory of Feature Toggles as something that has a carrying cost and strive to keep it low by actively pruning idle toggles. For example many teams have a rule that every new toggle must be accompanied by a task on the team backlog to remove it when its lifecycle is complete. Others put “expiration dates” on their toggles so that they are automatically removed at a predetermined date.

Regardless of the size of your inventory it is best to manage your Feature Toggles in some form of centralized location. Managing them via static files can become cumbersome at scale and it is difficult to ensure consistency across your entire fleet of servers. In most cases a centralized toggle configuration system is built out of existing application DBs and accompanied by some sort of UI which allows system operators, testers and product managers to view and modify the state of individual toggles.