When i was introduced to feature flags around 10 years ago i didn’t really understand them. They felt like a chore, an extra bit of code i had to add that the only thing it did was to make the code harder to read and add cleanup work after i was done with them.

Fast forward to now and they have become an integral part of my development work and i always advocate for them in any new team or company i work for. Although it is true that they add an extra overhead because you have to maintain them i believe that their benefits far outweigh the maintenance.

They simplify trunk-based development

Trunk-based development is a development technique were you don’t maintain feature branches for any amount of time, instead you write your code and check it in to the main branch of the repository. The beauty of feature flags is that they allow you to commit in-progress features that they may not work yet because they are kept safely behind a feature flag and that code is not executed.

They allow you to deploy code constantly

Because code from features that are not completed is not executed you can deploy your code at any point in time, being sure that no real user will be impacted by your changes. In my experience, a team that can safely deploy changes will deploy more often, and the more often you deploy the safer it gets.

They decouple the deployment from the release

Deploying code is a responsibility and decision of the development team. Releasing a feature, however, is not (at least, not completely): to release a feature you may need approval from a higher-up, you may need to launch a marketing campaign, you may need approval from a designer, you may need to wait for a specific date. The reasons to decide when a feature should be released to users are endless, and coupling the deployment process to those reasons is very inefficient. I’ve faced situations where i had several features coded but i could not merge them deploy them because we were not ready to release them, sitting in branches that got more and more out of date. Feature flags eliminate that problem.

They allow you to test a feature in a subset of your users

Once a feature is ready, different feature flag services allow you to partially release it: you can choose to release it to a small, random subset of users, or you can choose you release it to users from certain countries or even you can choose to release it to specific users. Feature flags give you granular control over who sees a particular feature.

They simplify removing code from a feature that didn’t work

Most features that a team releases won’t be beneficial, it is the nature of a development team to try ideas, learn from them and remove what doesn’t work. If you build a feature keeping all new code behind a feature flag, when it’s time to remove that code you know exactly what needs to be removed: everything that the flag is protecting! Not only this simplifies the clean up process but also allows you to know that what you’re removing won’t impact any user since the feature you’re cleaning up is (most likely) turned off.

Conclusion

In summary, feature flags is a great technique to write and deploy code without impacting users until the feature is completely ready to be released, and then, it allows you to decide who sees it and when. Especially in codebases with many people collaborating they are a great tool to increase confidence and velocity.

If you are new to feature flags or if you were not sure to give them a try, i hope i have been able to give you the push to try them.