Feature toggle driven develop development has been around for some time. Given the wave of DevOps and Continuous Deployments we are currently facing, the popularity of feature toggle pattern is rapidly increasing. Feature toggles aka feature flags are a common practice to enable trunk based development. Rezvan Mahdavi-Hezaveh et. al. from North Carolina State University recently released a paper researching “What are the feature toggle practices that software practitioners use?” and “How frequently are feature toggle practices used?”. This is our thoughts on the findings – and your key takeaways to improve your best practices in your organization.
The feature toggle best practices are broken down into 4 main practices; (1) Management practices, (2) Initialization practices, (3) Implementation practices and (4) Clean-up practices. In the illustration below, the 4 practices are added to a blueprint of the agile process.
These are the practices that the team does in order to manage and control the toggles. This category of practices includes
- Use management system – this is a centralized system keeping a central control of the feature toggles within the company. The management system will have a centralized dashboard making the feature toggle owner, current state, change history and similar information easily available to the team. A management system is connected to the source code, hence there is no need to manually update the information available in the management system. Unleash-hosted is an example of such a system.
- Use maintenance tool. This is similar to the management system, but the key difference is that the maintenance tool does not have any connection to the code. We strongly advise against this practice. The need for keeping supporting systems up to date using manual processes tends to get out of synch and lose it’s value.
- Log changes practice. Keeping a log of changes to the feature toggles is crucial if and when something goes wrong. In order for the team to learn, being able to look back into what really happened is crucial. Unleash-hosted supports this practice out-of-the box.
- Determine applicability of a feature toggle. The development team needs to decide if a feature toggle is a suitable pattern or not. Feature toggle do introduce more decision points in the code, hence increases the technical debt.
At unleash-hosted we consider this as an important step. There are two main reasons for that. 1) It will reduce the number of feature toggles in your code. 2) It will require the development team to take cautious decisions on how they manage their technical debt. We recommend introducing this practice to the early planning of a new feature to be developed. For advanced users, we would suggest that this practice is introduced as part of the communication between the product manager and the software development team. To discuss the release strategy with the product team makes the software development team aware and aligned of the business plans for the feature to be developed. Find more details on this topic here.
- Give access to users. Through this practice all the team members are given access to controlling and updating the state of the feature toggle. One example is Instagram that provide access to their product manager as well as the sales team for them to whitelist who should have access to a specific feature. Unleash-hosted integrates with your user authentication system for easy user management.
- Grouping of feature toggles. Grouping of feature toggles eases on the maintenance. How the practitioners are grouping the toggles differs. GoPro are grouping their feature toggles into simple and higher level categories. Other categories that is common, is to group according to the main categories of feature toggles; release feature toggles, operational feature toggles and experimental feature toggles. Grouping of feature toggles should be included in the grooming session of the work to be done.
Of the management practices identified, 4 of them is supported by most feature management tools today. These are important practices for the software development teams to work efficiently with feature toggle drive development, and the team is advised to take advantage of a best of breed feature toggle management system handling these practices.
These practices takes place before the feature toggle is brought into the code. It is advised to include these into the either the release strategy or grooming session of a new feature.
- Define default values – This is to ensure that the behaviour in the code is as expected. In unleash-hosted the default value is always set to off, unless other value is defined.
- Use naming convention – Use a naming convention is a good practice in general for software development, so also for feature toggles. Part of the naming convention a good advice would be to include its purpose, e.g. by prefixing the feature toggle with “Release”, “Ops” or “Experimental”. The of this is obvious; it is easier for new members in the team to understand the purpose of the toggle. Also, a good naming convention will also decrease the technical debt due to feature toggle. If a long lived “Release” feature toggle exists in the management overview, it is a clear indicator to the development team that it should consider to remove this feature toggle from the code.
- Determine the type of toggle – This comes back to the category of feature toggle that best suits the business needs.
These practices are highly dependent on the feature management tool you decide to use. The practices listed in this category are “Type of assigned values”, “Ways to access values” and “Store type”. Our experience is that software development teams tends to start by hard coding feature toggles into their code. This is an easy way to get started. Still, as we have seen from the past practices this approach usually develops into large separate projects as soon as the other needs defined by Management and Initialization practices are established.
To avoid increasing the technical debt because of feature toggles, clean-up practices are established. By using strategy constraints, the each feature toggle is the same across your different environments or tenants, which makes the clean-up easier.
- Add expiration date – part of the release planning or grooming, the software development team is advised to set a target expiration date on the feature toggle. A good advice is to add a reminder to the developer. One way this can be done in unleash-hosted, is to use the Slack hook and send a notification to the team channel on Slack as an expire reminder.
- Track unused toggles – unused toggles is technical debt and should be removed from the source code. Unleash hosted makes it easy to identify feature toggles that are not connected to any application.
- Limit the number of feature toggles – the idea is to put a hard limit on the total number of simultaneous toggles that are allowed. This is a practice we don’t advice to follow. The reason is that it is really hard to predict how many toggles that are needed for the team. The team should rather focus on considering if the feature toggle is needed or not.
- Create a clean-up branch
- Change into a configuration setting – The team may learn that the feature toggle served an unexpected purpose for its users. The team is advised to refactor the feature toggle into a configuration setting in these situations.
Usage of the practices in the industry
Rezvan Mahdavi-Hezaveh et. al. did investigate two categories of sources for their findings. First they research information available on the internet. Examples are google searches, blogs and similar. The findings were classified as internet artifacts, altogether 38 resources was put into this category. From the 38 internet artifacts, the team sent a survey to the 36 out of 38 where the team had the contact information. 17 did respond. The findings are found below.
These findings indicate that the industry is fairly mature when it comes to taking advantage of a management system. The biggest issue with the result, is that the data is based upon companies that are already using, or talking about feature flag driven development on the internet. Our key takeaway from these results, are the fact that the clean-up practices are fairly little implemented in the industry. This is well aligned with our findings published in the “Feature toggle lifetime – best practices article”. Here we found that over 50% of the registered feature toggles in our systems are 50 days or older.
What is clear – keep the number of feature toggles under control.
Ready to get started?