A toggle is a fastener that binds one end of a chain or rope to the other. It’s also a switch that can either turn something on or off; for example, the button you press to toggle between screens in video chat with two people at once. A toggle can also be a software feature that allows a team to develop and test features without impacting other features in production. For example, an e-commerce company might use a feature toggle to test algorithms that will be released in the annual sale without impacting everyone else’s experience.
When a feature is in a toggle state the feature’s code is completely hidden and invisible to users. However, a team has to keep track of these toggles as they move from state to state and update them when the time is right. It is not uncommon for teams to struggle with managing their feature toggle inventory as they scale from the prototype phase into more robust releases. The key to successful toggle management is a well-defined process and consistent communication within the team.
The first step in creating a process for managing feature flags is to decide which categories of toggles are most important for your product. Typically this involves choosing between the following four general categories of toggles:
Release Toggles
These are toggles that support dev teams as they write new features. They may have a short lifespan – perhaps just a week or two – although it’s possible for product-centric toggles to be in place for longer than that. In general, a Release Toggle is only activated when the team believes that it is ready for production.
Permission Toggles
This category of toggle includes those that are only available to premium users. These are often more long-lived than the other toggle categories but they are still transitionary by nature. This means that a team will need to be diligent about updating the feature when it’s ready for production.
For all of these types of toggles it’s crucial to ensure that you name the flags well and communicate their state clearly in any error messages that might be generated. This can help the whole team understand what the issue is and how to fix it. It’s also helpful to use a high-contrast color for the toggle’s state as this will make it easy for all team members to identify when it changes. Finally, consider adding an expiration date to your toggles to remind the team to remove them once they’re no longer needed. This can be a great way to encourage a more proactive approach to removing feature toggles from your codebase and will help reduce the risk of them impacting future testing or production releases.
