In the previous addition to our Fun with Flags series, we discussed how to store feature flags based on the category of flags they belong to.
We also discussed how flags are broken down into categories based on their dynamism and longevity.
In this post, we will explore the differences between short- and long-lived flags and which to choose depending on the use-case. We already touched upon this difference in the previous post but here we will go into more details.
Feature flag longevity
First, we will briefly define what we mean by longevity. This concept refers to how long the decision logic for a flag will remain in a codebase.
Feature flags, or features toggles, can be broken down into the following categories. Each of these categories serve a different purpose and thus should be managed differently.
Feature toggles can be categorized as the following:
- Release toggles– these are short-lived toggles that help developers in writing new features. They are usually on/off switches that control whether a feature is enabled or not. They are usually removed after the feature is released.
- Operational toggles– these are used to control operational aspects of your system. They are usually used to turn features off. They can be short-lived but it’s not uncommon to have longer-lived ones that serve as kill switches.
- Experiment toggles– these are used to perform A/B or multivariate tests. They will usually stay in the system for the duration necessary to generate statistically significant results from the feature testing so could be anywhere from a few weeks to months.
- Permission toggles-these toggles are usually longer-lived compared to the other categories of toggles, sometimes remaining in your system for years. They are used for user segmenting or, in other words, to make features available to certain subsets of users.
As we’ve seen so far, there are different types of flags, each used for different purposes and could stay in your system from days to months, even years, depending on how they are deployed.
Being aware of the longevity of a flag is crucial for a few reasons.
First of all, it is important when it comes to implementing the flag. For example, for short-lived flags, usually an if/else statement is sufficient but for flags that are meant to stay for a longer period of time will require more sophistication to support these flags and their associated use cases.
The second reason is to avoid the accumulation of technical debt, which will be explained in further detail in the next section.
Short vs long-term feature flags
This brings us to the key differences between short- and long-lived flags.
From the above, we can conclude that short-lived flags have a limited time span, meaning that they should be removed from your system as soon as they have served their purpose.
Long-lived or, in some cases, permanent flags are used for an extended period of time, sometimes beyond the release of a feature.
Long-lived flags become part of your regular software operations and infrastructure so you create it with the intention of keeping it in your system for an indefinite period of time.
It is crucial, therefore, to constantly review the flags you have in your flags.
Why is this important?
Flags must be checked at regular intervals to avoid the accumulation of technical debt. This debt might take a toll on your system, causing major disruptions and even resulting in a total breakdown, if you don’t keep careful track of it. The more flags you add to your system, the higher this cost becomes.
Thus, the best way to minimize this cost is to conduct a regular clean-up of your flags. Remove any stale, unused flags that you no longer use; otherwise, you might end up with hundreds, or even thousands, of unused flags.
However, this may not be as simple as it sounds. Often, when flag adoption increases, many organizations could find it difficult to determine which flags are still active so this process might become time-consuming and challenging the further you are in your feature flag journey.
Let’s take a look at how to overcome this challenge…
You will need to have a process in place in which feature flags are regularly reviewed and removed from your codebase.
For short-term flags, check to see if the feature has been rolled out to all users or no users and for more long-lived flags, you should determine if the flag is still needed for one reason or another.
You should also consider setting up access control, lest someone mistakenly ends up deleting a permanent flag that you’re still very much using! Thus, consider setting up permissions for each flag to assign who can delete certain flags.
Additionally, adhering to naming conventions, which indicate the flag’s longevity is a great way to keep track of the many flags you have in your system.
An advanced feature flagging platform can give you full visibility over all the flags you have in your system.
In particular, the Flag Tracking Dashboard and enhanced Git integration give you the ability to manage tech debt and see where your flags are being used. It also gives you the ability to reference your codebase and all your AB Tasty Flags, allowing you to quickly locate the flags that you are no longer using.
To sum up…
To review what we’ve seen so far, the following table lists each category of flag and its longevity:
| Category | Longevity |
| Release | From days to weeks (until the feature is rolled out) |
| Experiment | From weeks to months, depending on how long it takes to gather statistically significant results/Temporary |
| Operational | From months to years, depending on their use case. |
| Permissioning | Usually long-lasting/Permanent |
- Are you creating this flag for purposes of testing, rollout or feature releases? These flags are usually temporary (days to weeks) and should be removed once the feature is deployed.
- Are you conducting an A/B test? This must remain long enough to gather sufficient data but no longer than that.
- Are you using this flag to manage entitlements? This is when you give access to a feature to a certain segment of users. These are often long-lived or permanent flags.
As a final note: Review your flags often
In conclusion, make sure to review the flags you have in your system, particularly the short-lived ones, so that you can ensure they’re deleted as soon as possible.
The expected life-span of a flag will depend on the purpose it was created for so everyone in the team needs to have a clear understanding of the purpose of each flag in your system.
With that said, the most important takeaway is to make sure to schedule regular clean-ups to keep technical debt in check. As already mentioned, a third-party service will make the process less daunting by giving you full visibility of all your flags so that you can identify which flags need to be removed.
