This content originally appeared on DEV Community and was authored by David Herbert💻🚀
Feature flags (aka. feature toggles) are becoming increasingly relevant in software development as they provide the ability to toggle features on or off in production, perform a gradual rollout of features and enable A/B testing experiments.
However, an often overlooked part of this feature flagging technique is that it introduces complexity and has inherent risks when said complexity isn't properly managed. As you're using more and more feature flags within your organization, it's important to understand that some of these flags are meant to last only for a short period and should, therefore, be removed from your codebase.
Feature Flags Life Cycle (Longevity)
Feature flag longevity, as the name suggests, has to do with the lifecycle of a feature flag and how long it should remain in the codebase. Since feature flags split your code paths into two or more paths, having too many feature flags for a long time can create additional complexity in your system and an overabundance of them can easily lead to cognitive overload.
In addition, as with everything, when left unmanaged, feature flags can result in technical debt due to the presence of stale flags that no longer serve a purpose in your codebase. Having these stale flags can be a recipe for disaster as they can accidentally be toggled on. Thus, it is recommended that feature flags are kept as short-lived as possible and their number as low as only needed.
For these reasons, it is, therefore, necessary to evaluate the purpose of a feature flag to determine its lifespan depending on its use case.
Short-Term vs Long-Term Feature Flags
The first step when considering a new feature flag or keeping your flags organized is to identify whether a flag is going to be a short-term or permanent feature flag.
Short-Term Feature Flags
A short-term or temporary flag has a limited lifespan and is often used for release management such as dark launching a new feature, performing experiments, canary rollouts, and tests. When you label a flag as short-term, you can then keep track of it for removal in the future. Once the flag has served its purpose, the application configuration and code are immediately cleaned up, and the flag removed since it no longer has a use.
Long-Term Feature Flags
A permanent or long-term flag, on the other hand, provides certain control for an extended period, even after a feature is released. The flag might exist for as long as the feature does and is often used for things such as paywalls or entitlements, customizations, load shedding, or accessibility.
Flags that are long-lived easily become part of your regular software operations, so you create them intending to keep them around indefinitely.
Different Types of Feature Flags and their Various Life Span
There are different types of Feature Flags, and they are categorized according to their life span and use case:
Release toggles
Release Toggles are usually short-term flags used to slowly expose new features to users and also make it possible to keep certain functionalities hidden from some or all users while iterating on them. These types of Feature Flags make it possible for teams to continuously integrate new features into production without having to worry about the associated risks of continuous deployment.
Ops toggles
Ops or Operations toggles usually serve as “circuit breakers” to protect the system when integrating it with new features or functionalities to accommodate for potential issues. Ops flags are also short-term flags that are often used to determine the impact of a new microservice or infrastructure component on a system by monitoring it for possible unexpected errors such as CPU spikes or memory leaks. The ops flag can then be used to disable the new component for further troubleshooting if things don't go as planned.
Experiment toggles
Experiment toggles are short-term feature flags that are used for performing tests and experiments in a bid to collect data from real live users in production, such as carrying out A/B testing to decide between two or more implementation ideas.
Permission toggle
Permission toggles are usually flags that are used to customize the product experience of your users. This is done by limiting certain features to only a subset of users based on user entitlement or privileges such as subscription level or authentication status. We may, for instance, have a set of "premium" features that are available only to subscribers or paying customers. Unlike other toggles, permission toggles are usually long-term.
Dangers of Technical Debt and the Importance of Retiring Flags
Technical debt is a debt a company will have to pay later in the future for choosing a simpler, faster, but less reliable option today. And like all forms of debt, technical debt accumulates interest if not handled properly. This compromise can lead to a substantial amount of work and potential costs in the future.
As the popular saying states, "With great power comes great responsibility". One argument against using feature flags is that they contribute to technical debt. This is an understandable argument since you can quickly end up with several unused feature flags if you don't pay attention to your flags and conduct regular cleanups or reviews. In the absence of a removal plan, they will become obsolete and add technical debt and complexity. Having these stale flags in your application can adversely affect its reliability and increase development costs down the line.
Eventually, this technical debt accumulates and stays in your application for years and nobody is sure what a flag does. These flags can become tangles of conditional logic in your code which becomes challenging to manage in the future as your team will end up having to waste actual development time dealing with potential issues that might arise from stale flags.
It is therefore necessary to retire unused flags to avoid the technical debt associated with stale flags. Adopting a third-party feature flag management system such as ConfigCat can be sensible since the platform has built-in solutions such as tracking of stale flags and scheduled reports on your flags usage. This makes it easy to eliminate the technical debt associated with having stale flags in your source code.
Summary
Feature flagging is a very useful technique to have in your deployment toolbox for continuous integration and feature delivery in our application. Feature flags allow companies to ship more frequently, minimize risk, increase productivity, and even target users and perform A/B tests to determine which features are more popular with these users.
However, like so many techniques in software development, it also requires proper management and organization to avoid falling into technical debt as a result of misuse or mismanagement.
Having too many stale or long-lived flags adds complexity that accumulates into technical debt. Hence, the lifecycle of feature flags should be understood and properly managed by teams for the best results. Cleaning up stale flags and keeping the number of feature flags modest and as short-lived as possible becomes key in maintaining a sane and healthy codebase.
Be sure to check out ConfigCat's Feature Management service to discover how you can mitigate the frustrations of managing all your feature flags and you can also follow ConfigCat for more on LinkedIn, Twitter and Facebook.
This content originally appeared on DEV Community and was authored by David Herbert💻🚀
David Herbert💻🚀 | Sciencx (2022-07-12T21:52:32+00:00) Short-lived or Long-lived Flags? Explaining Feature Flag lifespans. Retrieved from https://www.scien.cx/2022/07/12/short-lived-or-long-lived-flags-explaining-feature-flag-lifespans/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.