A toggle is a switch that allows the user to turn something ON and OFF. It’s commonly used on keyboards and in system options menus where the user is given the ability to select from various settings (e.g., Airplane mode). It’s also a preferred control to use when adjusting settings on mobile devices because it takes up less screen real estate than two radio buttons.
When it comes to product development the word toggle can be applied to both hardware and software features that have a dual state, such as the Caps Lock and Num Lock keys on a keyboard. But it’s more often used to refer to the functionality of a feature that can be turned ON and OFF, such as a privacy setting or an experiment.
Feature toggles are a powerful tool that allow your engineering team to test new features with real users without risking the integrity of a production system. When a feature toggle is flipped ON, your users are exposed to the new tested feature; when the feature toggle is flipped OFF, your users see the original version of the application without the new feature.
One of the main advantages of using toggles is that they can be re-configured by your engineers without changing any existing code. This allows you to perform agile releases with a minimum amount of risk. This is much different than a traditional waterfall development model where the team would write and test new features on their own branches of the application before incorporating them into trunk code.
As you start to leverage feature toggles in your application, it’s important to have a system in place that manages the configuration of these switches. There are a few different ways to do this, ranging from simple but static approaches to highly dynamic methods that require more maintenance.
A simple way to manage toggle configuration is by hardcoding each switch in your application’s source code with a comment that specifies an on or off state. This method works well in small applications where the number of toggles is relatively low but can become cumbersome when your organization grows. For this reason many teams opt for a more sophisticated approach which involves moving the toggle configuration into some sort of centralized repository, often an existing application DB. This usually requires the build-out of some form of admin UI which lets your system operators, testers and product managers view and modify feature flag configuration.
Finally, it’s important to note that toggle configuration should always be based on the state of the switch itself; the value of a boolean should not depend on the value of any other fields or data in your application. This helps ensure that the toggle can only be re-configured by someone who actually has access to the database and prevents features from accidentally being rolled back out into production by an administrator who is unfamiliar with the feature.
