Feature Flags Management is a new software development technique that turns select functionality on and off during runtime, without deploying new code.
The product team use feature management to progressively deliver new code and features to end users, run experiments and A/B tests, customize the user experience, and maintain highly reliable applications—all while the application is running and without the need to deploy new code.
Why?
#1 Perform testing with selected users in Production
Simulating a true test environment is hard. There are many factors contributing to the issue user faces when they use our app, such as network connection, production database that is forever changing and costly to maintain if we were to simulate in the test environment, device status, etc. Not to mention the release cycle has become shorter after most companies adopted Agile methodology, there is simply too little time to test every single use case before releasing the feature to the users.
Here is where the feature flag comes into play. Instead of testing in the only test environment, we release the app with our feature but control with a feature flag and only show it to a selected group of users based on their profile, such as the heavy user of the feature, location, etc before rolling it out to all users. The benefit of this approach is getting feedbacks from the users quickly and fix the issue when they appeared. Plus, it will be easier for the team to monitor and gather feedback from the small number of users compared to the entire user base. Finally, once the team has satisfied with the result, we can just release the feature out anytime by toggling on the flags to all users.
#2 AB Testing
Testing is not only done to find out bugs in the app but also to understand user behaviour quickly. In a lot of time, the team has different opinions when it comes to deciding which colour, button, image or flow to choose. What is the best way to decide all these? Just let the user try it out and ask them which one they prefer.
Here is where AB testing comes in. Related to #1, the team can quickly create 2 types of the same screen, for example, one with a rounded button with text while another with a circle button with an icon. Then, through the use of feature flags, we can randomise and divide the users into 2 groups, A and B. A will only see the screen with a rounded button with text while B see the same screen with a circle button with an icon. Finally, the most important step is to gather user’s feedback, the team can integrate some tools to collect in-app user feedback, such as Qualaroo, Doorbell.io, Instabug, etc.
This is a good way to improve the app’s User Interface (UI) or User Experience (UX) without investing a lot of development time and getting users frustrated if the team chooses the UI/UX users do not like.
#3 Risk Management
Feature flags can also act as a failsafe button if anything goes wrong in production, which usually happens when releasing a new feature, having database migration, etc. How it works is having 2 flows: the previous flow and the new flow. If the feature flag is toggled on, then the user will continue to the new flow. If the feature flag is toggled off, then the user will go back to the usual flow.
When the customer support complaints the ad-hoc incidents to you, you can have peace of mind by toggling off the feature flags while taking the time to investigate and debug the issue.
#4 Releasing the Feature at the Right Time
Releasing the feature of the app at the right time during a marketing campaign is often crucial to a campaign’s success. Instead of having the marketing team always hurry or remind the developers to do the release for them at the right time for their campaigns, the development team can actually utilise the feature flags and give the marketing or business team the power to toggle on the flag, therefore releasing the feature out in the app at the time they want. However,
With great power comes great responsibility
Amazing Fantasy #15 (1962) the Spider-Man comic books written by Stan Lee
With the famous saying above, please make sure you Implement the safety measure before giving access to them, for example, by giving them only the access they need based on their roles or team and explaining to them what the flags can or cannot do so that they have a realistic expectation.
How?
#1 Naming Convention
A good naming convention for the feature flags is always a good practice for keeping things organized. Your teammates should be able to identify and understand what the feature flag does and what area of the application it affects just by looking at the name of the feature flag.
No best naming convention is suitable for every team. So, I am just sharing some good examples of naming conventions that you can take and modify for your team. The feature name example has 2 parts:
- Section of the app the feature is controlling, ex: homescreen, checkout, etc.
- What the feature flag does, ex: new_payment_flow, new_invite_flow, etc.
Naming pattern: section_featurepurpose
Examples: checkout_new_payment_flow, homescreen_new_invite_flow
#2 Feature flags documentation
Another good practice for implementing and managing feature flags is to document and keep track of the feature flags so that we can always refer to the documentation file to look for the owner of the feature flag and understand the feature flags. Here is an example of how we can document the feature flags.
- Name – The name of the flag in feature toggle.
- Person In Charge (PIC) – The developer who adds the feature flag. He or she is also the owner of the flag.
- Squad – Squad or team that is in charge of the flag. Here we will just use Squad as team.
- Lifetime – Permanent or temporary. Some flags are permanently set to have safety switch if anything goes wrong with the feature in production, ex: app crashes whenever user tries to invite their friends to the app. However, some flags are temporary, ex: the team is migrating to use a new payment gateway service, so we release the feature to the users by batch, eventually we will release to all users and remove the flags since it has served its purpose already.
- Description – What it does and where it affects. Although the naming convention helps to explain this but just document it here so that the developer can give more details about the flag.
| Name | Person In Charge | Squad / Team | Lifetime | Description |
| checkout_new_payment_flow | Yung_Kien | Payment | Temporary, to be removed on 31/8/2021 | Control access to new payment flow |
| homescreen_new_invite_flow | Luke | Invitation | Permanent | Control access to new invite flow |
#3 Make the switch at the feature’s entry point
The first place you should consider adding the feature flag is at the entry of every main feature of your app. The reason is simple: being able to toggle on or off when you want to turn the feature off. You might want to toggle off the flags when the feature is having an issue in Production and you want to switch it off temporarily to allow your users to use the app smoothly. Another possible scenario is when your server is overloaded when too many users were using a certain feature of the app at one time, so you can help by switching off temporarily other less important features, allowing the server to allocate the resources to the overloaded service. Example:
if featureFlags["checkout_new_payment_flow"] == true {
navigateToNewPaymentFlow()
} else {
navigateToCurrentPaymentFlow()
}Bear in mind that the features do not limit to just visible features, it can also include the features that are invincible to users, such as third party SDK.
You should also design your code to have a default option when you are unable to get feature flags from the API or have errors when calling the API so that the user is still able to use your app if it happened.
#4 Stages of Feature Flag Management
When the team starts to adopt feature flag management, these are the stages that normally we will go through.
Stage 0: Config file
This is where we usually start with feature flags. The developers create an array of feature flag values, then storing them in a flat file, finally call and read them at the initialisation of the app to get the feature flag values. Values are not changeable after the app has started and are not possible to customise the settings to different users. The values in the array will continue to increase until they become impossible to manage in a single file and the file risks losing synchronization with different deployments.
Stage 1: Database
At this stage, the developers have moved the flag values into the in-app database. The database can be updated and queried anytime in the app without the app restart. However, it is usually still difficult to customise behaviour based on each user profile.
Stage 2: Database with context
As the usage of feature flags grow, usually the team would want to add more context or strategy about the feature flags, ex: the owner of the flag and turn off the flag based on a certain user profile. The team also started to investigate any tools and add a simple UI in the internal portal to turn on or off the flags to make them more reliable and easier to maintain in long run.
Stage 3: Feature management service
Feature flags management has become an important part of the team’s process that required a dedicated service or team member to manage them. Now, it is no longer just a developer tool, but also a mission-critical business service. The feature flags are being evaluated on a daily basis and the squad controls and manage its own feature flags. We are also able to control app behaviour based on a per-user basis.
Usually, somewhere between stage 2 or stage 3, you should decide whether to invest heavily into developing the full-fledge feature flags management service or subscribe to a third party feature flag management service provider, such as Firebase Remote Config, LaunchDarkly, Split, etc.
Summary
Feature flags have become a critical component of the mobile application. Your feature flags management system must scale and be able to meet your business needs. Hopefully, the Whys and Hows outlined above can help you understand the need for feature flags and get started with feature flags by designing your very own or third-party feature flags management system.
I have included the reference of some good books on the topic of feature flag management below. They are really short books with a lot of good content in them, please feel free to download one and read up to understand in detail how you can design your own feature flag management system.
If you find this article helpful, please share it with your team. Also, feel free to leave a comment below to let me know your thoughts on Feature Flags Management. Thank you 🙏