In this article, I will explain the concept of feature toggles as I have understood and practiced them. Feature toggles, also referred to as feature flags or switches sometimes is a technique employed in software development to provide alternate paths without needing to maintain multiple branches in source code.
There are many uses cases and advantages of feature toggles. I have not been fortunate enough to experience all those use cases in my experience so far. I will delve into those that I have experienced and those that I have not but are fascinating to me.
Feature flags are essentially variables used inside conditional statements, enabling the blocks inside the conditional statements to be ‘toggled’ on or off depending on the flag. Imagine a scenario where a regulatory compliance requires your team to make some changes in the payment process when using internet banking in the next two months. There is a hard deadline for this compliance. If the team needs around two weeks to make these changes, then you are ready to release this change. But, payment is a critical feature that you may not want to disturb. This is where a feature toggle can be useful. You can create a toggle that will essentially allow some internal users to test the new payment process in production. This allows you to test a crucial feature like payment in production without disturbing the actual payment process for the thousands or millions of users who may be using the payment feature.
Feature flags are also used to perform a canary release. These are releases where a new feature is turned on for a small percentage of user base. One of the literal meaning of canary is an informer or a decoy for police. The ‘canary’ users provide useful feedback on the feature and thus the name canary.
As a product manager, this is where your mind must immediately trigger the concept of A/B testing. If a small set of users can experience a different user flow, can we somehow route users to two different user flows in run time and create an A/B experiment with a random sample. Yes, we can, using feature toggles. You can add sophistication and also implement a stratified random sampling if you have or can derive the necessary metadata for the users. Now, A/B testing for carousel images, button locations, marketing copy, etc. do not pique my interest so much as A/B testing a complete user flow with changes that may help us evaluate features in a systematic way. This is where feature toggles can be helpful and this is what fascinates me. I have not had the fortune of working for an organization that is wiling to do A/B experiments at this scale. There are also ethical considerations of A/B testing that one must keep in mind, particularly if the experiment is in domains like educational technology, where the learning children are the subjects of the experiment. I will write an article on those considerations in another article.
Another useful category of toggles are the release toggles. When feature flags are used as part of the continuous delivery framework, they allow in-progress and in-review features to be checked into the master while still allowing that branch to be deployed to production at any time. I believe this is how companies like Spotify release ‘hidden’ features that are released before they are completely developed to identify integration issues earlier. In some cases, the feature may be complete but the team may be waiting for an opportune time to match something like a marketing campaign or a seasonal event.
I have also heard about operation toggles where feature flags are used as a kind of load balancer to degrade non-vital system functionality. Imagine a prime day sale and a feature of the e-commerce website that has zero relevance to the prime day sale.
All this may sound cozy and exciting. It is, if used in the right manner. The usefulness of toggles can be shadowed by non-standard practices of creating toggles and creating what is known as toggle debt. In some organizations that I have worked for, toggles are spread out through the codebase like ‘land mines’ with no relevant comments, no feature to decommission the toggle in the product backlog, etc. Toggles may be used for short-term or long-term but not forever and this is something important from a product manager or a product owner’s perspective. I like to call it something like ‘the law of opposites’. Whenever you create a feature in your product backlog to create a feature toggle, also create a counter feature to remove the toggle, even if that needs to be removed after a year. This way, you or a future product manager will have visibility of the presence of that toggle and the need to retire that toggle at a later date.
If you are interested in more details about best practices of implementing feature toggles from a technical perspective, I highly recommend Pete Hodgson’s article on the same, available at https://martinfowler.com/articles/feature-toggles.html
I hope that this article provided some useful information, at least to some of the readers.
See you in a future article!
Sudhir Gupta's Blog 