Are you sure that’s a Feature Toggle? 🤨
Feature Toggles are a simple idea, at first glance. But if you scratch below the surface there can be a lot of nuance to them.
Martin Fowler has a rather brilliant post about this subject (well actually it’s Pete Hodgson’s post). I make no apology for having used the article very much as the foundation for this writing:
Maybe you should just click this link and read that article instead… seriously you should!
Different Types of Flags
As I inferred in the intro, simply saying “Feature Flag” can be a little bit dicey as there are several things that this can actually mean.
Release Flag
When we are developing code we usually want to get the code into production as soon as possible. Sometimes the code isn’t actually “production-ready”. We have a technique available to us to ensure that this code can both a) be deployed to production, and b) not ruin our Customers’ experience. We can hide this code behind a “Release Flag”.
Release Flags are especially useful when we are following Continuous Delivery principles and Trunk-based Development.
Release Flags should be short-lived (days or weeks). Once the code is complete, the flag should be removed.
Experiment Flags
At cinch we often run A/B tests to understand if a proposed change will positively affect Customer experience. When we perform A/B testing we will use an “Experiment Flag” in order to funnel Customers down the “A” or the “B” side of the experiment.
Experiment Flags should only stay in place for as long as is required to gain statistically relevant data and for a decision to be made (days or weeks). Once the decision is made, the flag and the “dead” side of the experiment should be removed.
Ops Flags
It may be desirable to control operational aspects of the product, these scenarios fall broadly into two categories, those which are short-lived and those which are long-lived. Either way, Ops Flags can be used to switch parts of the product on/off for operational reasons.
Short-lived Ops Flags may be used when a change is being made to the product which could be considered risky, e.g. it could introduce a performance problem. The Ops Flag can allow a fast cut-over from the problematic code to the original code, thereby limiting the impact on Customers.
Long-lived Ops Flags may be used to protect the product from uncontrollable circumstances For example if a 3rd party API because unresponsive, an Ops Flag would allow for the product to stop using the API and fallback gracefully.
Short-lived Ops Flags should be removed once the implementation they protect has proven reliable.
Long-lived Ops Flags will be few and far between but may be retained indefinitely.
Permissioning Flags
Many products will have areas that some Customers are not allowed to visit, for instance, the Premium features of a product which has a Freemium tier. Alternatively, there may be different parts of a product which are “Admin-only” for instance. To protect these restricted areas Permissioning Flags can be used.
Permissioning Flags are usually long-lived, and semi-permanent.
Static vs Dynamic Flags
In some circumstances “hard-coding” the route is preferable, such as with a Release Toggle. Whilst code is still under development, there is no need for the Flag to be able to be switched “on”, so an elaborate toggling functionality would be overkill. This scenario requires a “Static Flag”
Whereas in other situations, such as with a Permissioning Flag, the decision about which route to follow must be made on a request-by-request basis. This type of toggle requires a “Dynamic Flag”.
Long-lived and Short-lived Flags
Flags will usually either live for a few days/weeks or semi-permanently. It stands to reason that we should put more effort into the implementation quality of long-lived flags, than short-lived flags.
For instance, short-lived flags are probably fine to be implemented using a simple if/else based on a hard-coded value or environment variable. However, a long-lived flag, perhaps used as a kill switch for an unreliable 3rd party would need to be implemented in a much nicer way, perhaps using a for-purpose platform to manage it.
It is important to be mindful of the life-cycle of a flag when choosing the complexity/cleanliness of the implementation.
And there we have it. The humble Feature Toggle is in fact a many-faceted beast. So next time you are looking to use one, have a think, what’s it for? is it short-lived or long-lived? is it dynamic?
