Toggle is a term used to describe a switch that has two positions, on and off. Oftentimes this switch is used to control a view, setting or piece of content. In software development we use toggles to help people manage the state of their apps. It is important to keep in mind that a toggle should only allow people to control the state of something. Anything else should be managed through another component such as a slider or menu.
When creating a toggle we need to make sure it clearly communicates its purpose. This is often done through the use of an icon and changing the toggle’s color to reflect its current state. We also need to make sure the visual cues we use are accessible to users with disabilities. For example, using the color red to signify an on status could be confusing for some groups of people who associate this color with traffic signals or stop signs.
Adding an Ops Toggle to our application will give us the ability to dynamically re-configure specific service instances, which can be very useful for experimenting with new features or for performing manual exploratory testing and debugging. This is an extremely powerful tool that comes with a great deal of responsibility. It is only suitable for features that can be safely re-configured at scale and should not be used in production environments.
If we are going to implement an ops toggle in our application we need to have a good way of managing the toggle configuration. One approach that is fairly simple but not very dynamic is to hardcode the toggle’s settings in a piece of code using something like a preprocessor’s #ifdef feature. This is fine for low-traffic use cases but can be difficult to maintain as the application grows. In most cases it is much better to store the toggle’s configuration in some kind of centralized store, typically an existing application DB. This allows us to easily modify the toggle configuration and can be backed up by an admin UI that makes it easy for system operators, testers or product managers to view and manage feature flags.
Another common use case for an ops toggle is to perform multivariate or A/B testing. For example, an ecommerce company might want to test two different suggestion algorithms in their configurator to see which performs best. In this scenario the team would create an experiment toggle in their production configurator and assign each user to one of two cohorts. The experiment toggle will then send them down either the A or B algorithm based upon their membership in the cohort. Once the team has conclusive data they can remove the experiment toggle and deploy the winning algorithm to all users.
Savvy teams treat their feature flag inventory as something that comes with a carrying cost and try to minimize its size. To do this they are proactive about removing toggles that have not been tested or that are no longer needed. Some teams have a policy of adding a task to their backlog for toggle removal as soon as they add a new one, while others put “expiration dates” on their toggles which cause them to fail an automated test if they remain active after the date has passed.
