When implemented properly, toggles are a powerful tool for hiding or exposing features to users. However, it’s easy to over-use them and end up with a complex set of switches that are confusing for users and a nightmare to debug weeks or months down the road when they start to break in unexpected ways. To avoid this, here are three criteria you should use to determine whether a toggle is the right control for a given situation.

Toggle Configuration

There are many approaches to managing the configuration of feature toggles ranging from very simple but less dynamic ones (such as hardcoding the state of a flag in a code comment) through to some that are more sophisticated but require a specific pattern of deploying a release in order to swap out the toggle state for a new one. Regardless of the approach used it is important that any method of toggle configuration live side-by-side in source control in order to make it as easy as possible for the whole team to manage the state of a toggle.

For instance, some teams have rules of always adding a task to remove the toggle to their backlog whenever they introduce it. Others put expiration dates on their toggles to force the removal of unneeded flags. This helps the team stay organized and reduces the risk of a mis-configured toggle accidentally staying active for far too long.

Another way to help organize and keep track of feature toggles is to create a naming convention that makes it easy for any member of the team to see what each toggle is doing at a glance. This is an especially helpful practice when it comes to logging bugs as it allows the team to quickly identify a bug that may have been introduced due to an incorrect implementation of a toggle.

Toggle Usage

Using toggles as a development process supports agile approaches and speeds up the time it takes to release software. Traditionally, a new feature would be written on a separate code branch and then go through a testing and QA process before being merged back into trunk code. This process is not only slower than an agile approach but can leave the code vulnerable to defects until it has been tested extensively and reintegrated into trunk.

A common case where a toggle might be used is to test an experiment against a production algorithm. For example, an e-commerce company might run an A/B test of two different suggestion algorithms to see which is more effective at helping users complete their orders. In this case the e-commerce company might add an experiment toggle to the configurator so that the two suggestions can be tried by a random cohort of users. Once they have conclusive data the e-commerce company could then remove the experiment toggle and make algorithm B live for all users. In this way a simple toggle can allow the creation of a more complex experimental feature without needing to do the additional work of creating a separate code branch or running a longer experiment.