Feature flags Pt 1: Faster feature development with flags.
The greatest accelerator of my team's work last year was adopting feature flags. With flags we ship features faster, more confidently and with less stress. We have fewer merge conflicts despite frequently working together on the same part of the code base.
Saracen Joust in Arezzo: Exhibition of the flag-wavers from Archivio Istituzione Giostra del Saracino del Comune di Arezzo
In this post I will share the advantages and potential pain points we have seen. For context we are a team of 5 developers working together on a back end api and front end web app for business users. We have moved towards trunk-based development, avoiding long-running branches.
What are Feature Flags ?
A feature flag lets you turn parts of your code on or off for some or all users, or based on other conditions such as date, time, region, etc.
✅ In this post I am talking about short-lived flags used during development.
❌ I am not talking about permanent aspects of your app such as customisations for individuals or groups of users.
Advantages
- Fewer merge conflicts 🎌. This is the biggest plus: Hiding features which are incomplete or not yet launched behind a flag lets you merge more frequently safe in the knowledge that the new feature is not going to break existing code. By sharing more often, avoiding long-running branches, you hugely reduce the risk of big merge conflicts
- Earlier collaboration 🏳️🌈. Sharing your code earlier means you can start collaborating quickly with other developers, product, sales and designers. There is nothing better for discussion and collaboration than working code.
- Early feedback. By turning on features for trusted customers and partners you can get early feedback on the design and functionality.
- Increased productivity. All of this means you are shipping impactful changes earlier with less wasted effort.
Pain points
Sounds too good to be true? There is no such thing as a free lunch - here are some possible downsides:
- Upfront investment It takes time to develop a feature flag system or adopt an external solution and you need to convince the team that the effort is worth it. I hope this blog post helps with that! Adopting feature flags may imply changes to your branching, code review, deployment and ci / cd system.
- Complexity Each flag adds a new code path - be wary of layering complexity or nesting flags in complex ways. Creating, updating and deleting each flag takes time so do not add them unnecessarily for small features.
- Removal At some point the flag code needs to be removed. Avoid keeping unused features behind deactivated flags or accepted features inside permanently active flags "just in case".
Recommendations
- Start small In our team we started with the smallest possible shareable system - a flags namespace in our front-end code. We later adopted an existing open source library in the back end.
- Work together. Ensure that everyone is adopting the system where appropriate, discuss any challenges as a team and look for solutions. Change course as necessary.