In part 1 of this series, Steve Upton and I argued that feature toggles should be flippable or dynamic as a sensible default. While I personally still hold this opinion, I see that this is the most controversial point on the list of suggestions from that article and there are good arguments for having static feature toggles instead.
Since the piece was published, I have heard many arguments for and against dynamic feature toggles. Therefore, I want to describe the advantages I see in both approaches and outline when it can make more sense to use static feature toggles.
Static feature toggles
Static feature toggles are feature toggles that have their state hardcoded. To change its state, you will need a new commit and deployment.
What are the advantages of static feature toggles?
If you aren’t using any toggles already, static toggles are easier to set up. They don’trequire any framework as they can just be boolean flags that can be set, for example, in a properties file. In many cases, it’s enough to ensure that only the state which is currently set for the live environment is fully functional; this can make testing the toggle easier.
Since the toggle is static and does not require any database or API call, its existence is unlikely to affect the performance of the application (as discussed in part 2). For dynamic toggles, failing network requests can also lead to features becoming temporarily unavailable or, in extreme situations, to a local outage of the entire application. This can be avoided by using static toggles. A static default value for the dynamic toggle (false before release, true after release) can support us in these situations.
The static toggle also doesn’t add any external dependencies — this is useful as those can be additional points of failure.
Finally, an advantage for debugging issues is that the current state of each static toggle is documented in the git version control. For dynamic toggles, you’d need to implement some kind of tracing for each state change in order to figure out what the toggle configuration was when some defect occurred.
Static feature toggle use cases
Since static toggles are simple to use with no extra effort, they can be considered an intermediate step when a team decides to move towards using toggles but lacks the time or experience to set up a framework for it. They are also useful if a team just wants to try out techniques like trunk-based development (TBD) which are enabled by hiding unfinished features using toggles, or for technical features such as infrastructure changes, where it is unlikely that the toggle is going to switch back and forth a lot.
Since static toggles don’t require any database or API calls, they are particularly good for use on the client-side of an application because they reduce delays and data usage. Pete Hodgson goes into further detail on how to cater to the client-side by using static feature toggles in this blog. For the same reason, static toggles can help hide features which are very frequently used (e.g. millions of times per minute); this can improve performance by removing the need for millions of database queries.
Dynamic feature toggles
Dynamic feature toggles can be flipped at any time within a matter of seconds, by any stakeholder in the team. Their state is stored in a database, query parameter, or similar.
What are the advantages of dynamic feature toggles?
Dynamic feature toggles enable true continuous delivery, where the release of a new feature becomes a business decision. When used, stakeholders won’t need to wait for a new deployment — which might be blocked by a red pipeline or similar reasons — but can simply flip the switch themselves whenever they deem the feature should be released to their customers.
Additionally, the dynamic toggle lets the team use it as an emergency switch if anything goes wrong after the release. The feature will be rolled back within a matter of seconds, allowing the system to recover.
A nice-to-have of dynamic toggles for me is that I can present a feature preview to stakeholders, quickly switching between the “old world” and the “new world” without the use of screenshots or other hacky ways like having multiple environments with different configurations. Furthermore, dynamic toggles can carry context to enable features only for specific users or regions, and thus can be targeted at specific audiences.
This quick switch can also support the QA work to observe multiple dependent unfinished features in progress. Be mindful that all possible states of the toggles must be valid and tested in order to unlock the advantages above.
Dynamic feature toggle use cases
Dynamic feature toggles are a great addition to a mature team that already does TBD and has a CI/CD pipeline — without manual deployment steps — already in place. The benefits of dynamic toggles can also bolster your argument when encouraging non-technical stakeholders to invest time in a toggle setup and to get the team involved in practices around managing the toggles.
The strengths of dynamic toggles lay in stories which are more business-oriented, like UI changes or other visible updates to your application. Advanced release processes like canary releases, A/B testing and multivariate testing as well as testing in production can be achieved when using a dynamic toggle framework.
If unfinished features are potentially interacting with each other, it’s a lot easier to test this with dynamic toggles where any combination of features can be tried out before releasing them into the wild. Sometimes, these dependencies only become apparent when trying out the new features.
Conclusion
The question whether to use static or dynamic feature toggles leaves us with the good, old consultant’s universal answer: It depends! There is certainly no correct answer, but I feel it can be a good conversation starter to reflect on your team’s use cases for toggles and where your priorities lay.
Nevertheless, I personally will continue thinking of dynamic toggles as a sensible default to aim towards unless the team’s situation heavily suggests that this is not the right tool for this time or this use case. The business advantages are striking for me; once a setup for dynamic toggles is in place, they become a reasonable approach for most new features.
Read the rest of this series:
- Part one: Managing feature toggles in teams
- Part two: The limits of feature toggles
- Part three: Feature toggles and database migrations
- Part four: Testing feature toggles
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
