Toggle is a term used in computing to describe a switch that can be set in one of two states: on or off. They are a common way to change settings and preferences in many applications and devices including computers, mobile phones, TVs, cars, home appliances, etc. The toggle control is often preferred over a radio button or checkbox because it takes up less screen space and can be more easily understood by users as a yes/no decision. A toggle also has a distinct advantage over a checkbox in that the user can see exactly what will be changed in an instant, rather than having to click Save or Confirm.
In some cases it may make sense to have a toggle that changes both state and value, such as the privacy setting on Google Accounts. This allows the user to decide how much Google will store of their browsing, search and location data and choose whether or not they want Google to automatically clear this information after a certain period of time. This type of toggle is commonly referred to as an Ops Toggle.
There are a number of ways that teams can manage toggle configuration in codebases from some which are quite simple but relatively less dynamic through to some which are very sophisticated but have significant additional overhead. Some teams use static files to manage toggles which can be accessed and modified by system operators, testers or product managers. This approach can become cumbersome if the number of toggles grows and it is a good idea to build out some form of centralized repository with an admin UI for this purpose.
Some teams prefer to have a more dynamic way of managing their toggle configuration, typically using an existing application database. The benefit of this is that the toggle configuration can be accessed and modified in an automated manner by test scripts and there is also some flexibility around how the toggles are re-configured. This is generally best for Ops Toggles and some types of Release Toggles although there are situations where this approach could be appropriate for all toggles in a release.
Ultimately, the decision to opt for either a static or dynamic method of managing toggle configuration is a product and market dependent one. The key is that the toggle configuration should be able to be changed in a timely manner, especially for Release Toggles. Savvy teams recognize that feature flags carry a carrying cost and seek to keep the inventory low by being proactive in removing old toggles from their release pipelines. This is sometimes done by simply adding a task to the team’s backlog at the point in time when a new release with the toggle flipped On first hits production.
It’s also a good idea to do some testing with the toggles that are expected to be released flipped Off so there are no surprises in a future release. Some teams go so far as to add expiration dates on their toggles, ensuring that they will be removed from the product once they are no longer needed.
