A toggle is a switch that is flipped to either on or off, as used on many electronics. In the context of software development, it’s a way for engineering teams to rapidly test ideas or new code in a real-world environment without risking their entire production application.
Toggles are a tool for easing into experimentation and to foster an environment where people feel comfortable making bold decisions. Feature toggles allow engineers to test assumptions and encourage them to push the product in the direction they want it to go. Rather than saying “I don’t think that will work” and avoiding the change, people feel more comfortable trying out an idea and seeing what happens, which makes them more likely to try out other ideas.
In addition to testing and monitoring the effects of a new feature, a team can use toggles to perform a variety of operations. For example, an e-commerce company may want to test two different suggestion algorithms in their configurator. They can use an experiment toggle to bucket users into one of the two options and determine which algorithm is more effective for their customers. Once they have conclusive data, they can roll out the new algorithm and remove the experiment toggle.
Operation toggles are typically only active for a few days or weeks at most before they’re retired. However, product-centric toggles can remain in place for longer periods of time if necessary. They are also useful for performing maintenance on an application during high latency periods by temporarily disabling non-essential features.
It is important that a team has a process for vetting when to use a toggle and how to manage its lifecycle, as this impacts the cycle times for CI/CD and ultimately the speed at which your application gets to market. Additionally, a team should be sure to regularly prune any old toggles that are no longer needed. This prevents the codebase from becoming cluttered and can be done by adding toggle removal to your team’s backlog or building the process into the management platform.
Toggle configuration is often stored in static files, but this becomes cumbersome as the quantity of toggles grows. In addition, changing the configuration of these files can be a lengthy and tedious process. To help mitigate this, many organizations move toggle configuration into some type of centralized store, usually an existing application DB. This also enables administrators, testers and product managers to quickly access the toggle configuration and change it as needed.
Finally, it is crucial that a team tests the toggle configuration that they expect to be live in production. This includes all toggles flipped ON, as well as the fallback configuration (all toggles flipped OFF). Testing this will ensure that any changes to production are not unintentionally causing regressions for users. It’s also wise to run tests with all toggles flipped ON so that the team can be confident that the system is stable and ready for release.