Day 12 - Feature Flags 2
Or What my engineer means when she says: "Do you want to release our <big feature> incrementally with feature flags?"
Recap on Feature Flags 1
Yesterday we learned that by using Feature Flags (FF) we can control how a piece of our software, or a product feature will be distributed among our users.
We talked that we may want this because of:
Rollout released in stages
Compare two variations at the same time (e.g. in A/B tests)
The feature is temporary and is relevant for a portion of users (e.g. Alert boxes, Reminders, ...)
Any standards?
Depending on what you want to do, Feature Flags' design and implementation can be straightforward or a nightmare.
Even though there are several tools and services that provide A/B testing and Feature Flags functionality, integrating with them and their cost are hurdles in their adaptations.
So most of the FF systems I worked with, were implemented in-house (and that works well, thanks to very talented engineers who worked on it).
Best Practices
I'd like to touch on some practical aspects of Feature Flags that I learned over the years using them in production.
Server-side vs. Client-side FF
Most of the tools I am going to mention in the next section are helpful for Client-side testing. But what is Client-side FF and how they are different from Server-side?
Client Side Feature Flags
... are done by placing a cookie on the user's browser to determine which variation of the test to show them.
It's mainly useful for testing on Landing pages and websites where there isn't any login required to see the page or content.
Server Side Feature Flags
Whenever you need to play around with features behind a login, for users, things get more interesting.
In these cases, a simple cookie
will not help anymore and your app needs to read the flags from your server (the backend, or your FF management provider).
In this case, having FF management (either developed internally or from a 3rd-party provider (3pp)) is more important. Using this tool, you want to have these functionalities:
Create a new feature flag and see a list of all active/inactive ones.
Assign users (or customers, if you are in B2B) to it in several ways, such as: At random based on a %, predefined. customers based on a property (email, location, ...)
Enable or disable it with ease. (make sure your software handles the edge cases).
Some fancy 3rd party tools also provide tracking and reports on the feature flag (how many users/customers saw it, ...) but this is not a must. You can track this better in your own Tracking plan (topic for another day). It's more of a nice-to-have.
All of this helps you to be independent of the engineers and modify the App's functionalities based on the real-time data, with a toggle of a switch, rather than a new code deployment (and going through all the 3-4 environments, remember Environments?)
Remember that you would still need the newly created feature flag to be in the code, so initializing a feature flag on the dashboard is not enough. But after your engineers insert it in the right place in the code (see the code example below), you can control the feature from the dashboard.
Flags should Enable functionalities
Even though feature flags are simple boolean
variables, it's important to use them as "enablers" and not disablers.
This is especially important as you move to Server-side FF because there might be a lag while getting the FF from the server or even a bug in FF implementation (a small typo for example), and in these cases, the software needs to default to the standard features, not the experimented ones.
Let me give an example:
Let's say you just finished developing a fancy new widget on the dashboard of your app and you want to roll it out for 10% of the users if it is working well, and is useful for the users, and ... (all the product usability things).
You can do this in two ways, logically:
Enable the widget for selected users (what you should do)
Disable it for the users who are not selected (oh no 🙈)
In this case, you should opt for naming and default values in the following way (in pseudocode):
// default value if for some reasons, ff_manager is not working or the variable doesn't exist
if (ff_manager.show_new_widget(user_id, default = False) ){
// insert the new widget
} else {
// do nothing :)
}
Be careful of conflicting feature flags
If you are running lots of A/B tests and are not careful with defining the scope of Feature Flags, your end data may not be very reliable, depending on how the code is implemented.
This is more of a nuance in the implementation detail, but keep an eye on it and go through it with your engineer to make sure the feature flags are working as expected.
Tools and software
As I mentioned before, I've only used internal implementation of Feature Flags functionality but during the implementation and discovery, I've checked a few providers that are worth mentioning. With a simple Google search, you can find many providers. Some have public pricing, but others require contacting their Sales team to get a quote (which is very annoying IMO.)
⚠️ Disclaimer: I'm by no means sponsoring or promoting them. Your own due diligence before purchasing or integrating with them is required.
These tools are:
Google Optimize (https://optimize.google.com/)
Firebase Remote Config, also by Google (https://firebase.google.com/products/remote-config)
Optimizely (https://www.optimizely.com/)
VWO (https://vwo.com/)
LaunchDarkly (https://launchdarkly.com/)
Statsig (https://statsig.com/)
Flagship (https://www.flagship.io/)
Feature Flag by Split: https://www.split.io/product/feature-flags/
CofigCat (https://configcat.com/)
References
Some good articles and resources I came across while I was researching Feature Flags:
Feature-Flags (https://www.feature-flags.net/)
A great article by JOSH PITZALIS on nitty-gritty details of Feature Flags: https://usabilitygeek.com/a-b-testing-the-words-in-your-product/
All the tools above :)
Slides for today’s post
Here is the slide for today’s post.