One of the most important techniques to me in building digital products on the web is using feature flags. When used correctly, it brings adaptability where it’s most needed, enabling a powerful alignment between product and development.
Feature flags are certainly not new, but I think it is still most effectively learned by trade for reasonable scales. Most tooling and resources I’ve seen tend to go through how to do it for a hyperscale.
So it might be interesting to go through some things that I learned along the way.
Keep them simple
It seems to be a very popular thing to overdo feature flags. So much so that it was emphasized in a TechRadar by ThoughtWorks.
While there are specialized products like LaunchDarkly, they are also expensive and packed with features that you might not need – yet, or anytime. Most platforms have tools that you could use instead, with little adaptation (e.g. Django permissions as feature toggles).
Not broad, not specific
I’d say the hardest part is finding the right equilibrium between having broad feature flags (not useful) and overly specific (configuration nightmare).
This is something that has been widely covered by more experienced and well-versed people. I’d say that it’s one of the most important things, and you just have to practice it. Like architectural katas.
Simplify your Git workflow
While it seems obvious, one amazing possibility of using Feature Flags is that it decouples deploying from releasing. That means that you can have multiple people submitting production-ready code to a mainline branch without concerns on deploying specific versions.
This removes friction on merging and the potential for a branching hell.
Leverage its power on many fronts
Once in place, Feature Flags come in handy as a multi-purpose tool.
- Incident? Quick mitigations can be in place disabling features or gates.
- New pricing structure? Crafting new plans with different feature sets can be done quickly with flags.
- QA & Beta users? That’s an easy one.
- Feature refactoring? Start building new features right alongside the previous ones and hide those changes from general availability.
Have cleaning days
One of the biggest problems might arise from having too many feature flags. While that is something that can happen if we are not careful, it is something that eventually will happen as time and product evolution march on.
Flags that were initially heavily atomized can now be consolidated into more clear business functions, others that were introduced for feature refactoring are now not needed.
Be thorough in keeping it tidy, and have scheduled quarterly cleaning sessions.
Salute!
Juan Saavedra 