Feature Flags are software switches that turn on or off a feature - usually in real-time, without needing to release a new version of the software. For instance, if you are shipping a new feature and you want to be able to control who gets to see your new feature and who shouldn’t, then you use Feature Flags to accomplish that.
if (user.shouldSee("my_new_feature")) {
showNewFeature();
} else {
showOldFeature();
}
They also go by many names: Feature toggle, switch, flipper, conditional feature, and more. “Feature Gate” is Statsig’s chosen terminology.
Until about 10 years ago, big-bang software launches were the norm. Every new version of a product was usually a large undertaking and took months, if not years, to launch. Here’s a timeline of Microsoft Windows launches. Each version until Windows 10 was a large installment with thousands of code changes packed together, and each version took about 2 years to ship.
But those are the old days. Nowadays, most software is updated on a much more regular and frequent basis (Operating Systems included). For instance, Facebook was pushing code on a weekly basis until about 4 years ago when the company switched to “continuous and immediate deployment” where every commit goes to production after a few sanity tests are passing. This is more widely referred to as Continuous Deployment.
https://engineering.fb.com/2017/08/31/web/rapid-release-at-massive-scale/
In this modern, continuous deployment style, Feature flags are useful in a variety of ways. They can decouple development and release decisions, validate features prior to launch, break timeline dependencies between multiple teams, launch time-sensitive features, and more. Any one of those use cases improves software development speed and safety; taken together, feature flags become a powerful tool for modern software development.
By putting all new features behind a Feature flag, development teams can keep building at their own pace. Because the feature launches can be controlled through these flags, the product or business team can independently decide when to release these features to users. This reduces project timeline risks because development teams don’t have to serialize product development and shipping cycles.
The ability to partially turn on a Feature flag allows product teams to test a feature in production using a technique called a “Canary release”. This is achieved by allowing a small portion of production traffic to be sent to the new feature to measure and validate the metrics associated with the feature. Once the impact of the feature has been measured, it can be turned on for a wider audience.
Oftentimes different teams take dependencies on each other. For instance, when building a new mobile app feature, the mobile team will need to take a dependency on the server team to provide them with the right APIs. This means that mobile app features cannot be shipped without having the server features deployed. And if there are changes needed, the server has to be deployed again before the new mobile features are sent to Apple or Google for verification.
By using Feature flags, the mobile and server teams can continue shipping at their own schedules, but have the features behind these flags. They are no longer tied to each other’s launch schedules. When both sides are ready, they can collectively decide when to simultaneously open the gate for both the server and the client side features.
Imagine an ecommerce app wants to run a Mother’s Day promotion for that specific weekend. It’s hard to time a product release exactly at that time and another one when the promotion is over. Instead, the promotion feature would be shipped behind a Feature flag. At the right time during the Mother’s Day weekend, the team can turn on the flag. Once the promotion is done, they can toggle it back off - all without needing new code deployed. Better yet, you can add a time-based condition to your feature flag to manage this rollout (and subsequent rollback) automatically.
Feature flags can be used as a quick way to shut-off a feature that’s already launched. Flags are typically used to killswitch code that has a serious bug in order to limit user exposure to that bug. Feature flags are extremely valuable in such situations and can act as a quick way to turn off the offending feature/features, or better yet, to turn off the feature only for the specific app version/location/browser/etc where the bug reproduces.
By offering such detailed analysis without needing to write any additional code, Statsig stands out in helping teams consistently and repeatedly ship only the right features that are positive to product and company metrics.
