10 Best Practices for Feature Toggles
It is likely that during our lives as software developers we have used feature toggles, also known as feature flags. These give us the ability to modify our software by making just a few changes. Feature toggles have numerous uses, from A / B experiments, to showing new functionalities to a subset of our users, granting specific permissions, hiding functionalities that are not finished yet, and many more. But with great power comes great responsibility, in this article we will point out some good design patterns when defining, using and maintaining feature toggles.
1. Use descriptive names
Using a name that describes what the feature toggle was conceived for can save you and your colleagues a lot of headaches. Naming is hard, that is why we must take the time to find a good name.
2. Documenting is not evil
Not always everything fits in one name. For that reason it is advisable to write some documentation, it can be as simple as a comment on the definition. If we use a SaaS for feature management, it is very likely that together with the name we can enter a brief description. It is important that this documentation is visible to those who will have access to change the status of the feature toggle. Although documenting is not always pleasant, it is an investment and pays off for the time spent.
3. Don’t let it get old
Although this pattern does not apply to all types of feature toggles, it’s important to keep track of when they are no longer in use. It is true that Ops or Permissions Toggles do not necessarily age, however, those that we use for A / B experiments or to hide unfinished functionalities can become obsolete very soon. It is advisable to use them for the shortest possible time, which can be from hours to a few weeks.
4. Beware of loops
Using feature flags within a loop is not a bad practice, but it is recommended to access the value before entering. One of the reasons is obvious, efficiency. Checking the value stored in a variable is more efficient than constantly checking the status of the feature. Another reason is that if we have dynamic feature toggles we can introduce bugs in our code.
5. Use typed variables
Whenever possible, avoid consulting the feature toggle by accessing directly with the string. Instead, use typed variables, this way it’s easier to re-factor the code, and you can use the benefits of the IDE such as renaming.
6. Keep it simple
Try not to use the same feature toggle in multiple layers of the application. If possible, gather all the logic in one place, so you will have a more maintainable and extensible code. If you have to remove the feature toggle you will know exactly the only place where a change is necessary.
7. Don’t reuse a feature toggle
Features flags are for “free”, do not reuse one that already exists. You will be a little tempted to reuse one if it already has a descriptive name and is well documented, but be careful about doing this in any case. This bad practice of recycling feature toggles can lead to bugs and unwanted behavior when other colleagues are not aware.
8. Keep audit logs
It’s good to know who has changed a feature’s status and when. If you use a version controller you can use the blame and log functionality. In this way we can see all the states through which the feature toggle has passed. If we use a SaaS it is likely that we have this functionality out-of-the-box.
9. Select what type you need
As we have previously mentioned, not all feature toggles are the same. Find out which ones apply best to solve your problem. I recommend you start with the Martin Flower article https://martinfowler.com/articles/feature-toggles.html and continue with other books and articles. Selecting the right one will avoid unnecessary re-factoring in the future.
10. Don’t reinvent the wheel
There are many services that offer feature toggle management. If you find one that fits your needs, use it. These services offer many benefits that we can exploit to improve our processes. For example, enable or disable a toggle without the need to re-deploy our application.
