There are often times when you’re building a feature, and have broken it into smaller user stories. But this new feature won’t be completed for a month, and you’re releasing into production every week. You can’t break the continuous integration build cycle, but you also can’t release an unfinished feature.
What’s a PM to do?
In the old days, you would:
- Deliver stories that were part of a new feature individually to staging
- When it was time for your weekly deploy, engineers would pull this code out of HEAD and stash it in a branch.
- Deploy that stripped code to production.
- Engineers would remerge this code to HEAD on staging, hopefully with no merge conflicts.
- Cross your fingers.
This process is dangerous for a couple reasons:
- You and your team could forget to remove this partially-completed feature, releasing something half-baked
- A production deploy takes time. If you’re announcing new features at a big conference, you can’t afford to take down the site for a deploy. And what if it fails on something else unrelated?
Introducing feature flagging:
Simple in nature, feature flagging means to wrap logic code around certain pieces of code that aren’t ready for prime time. The code goes out to production, but the code logic ensures that it isn’t shown.
BENEFITS FOR PRODUCT MANAGERS
- Doesn’t interrupt regular deploy cycle
- Can turn a feature on immediately without require a deploy
- Allows breaking a large feature into smaller stories
- Lightweight in development cost
BENEFITS FOR DEVELOPERS
- Painless way to test if a specific feature would hammer the server
- Prevents accidental deployment of unreleased features
- Avoids merge conflicts
- Additional code to maintain
- Need to remember to spell out this requirement in each story or it will still go live
- Not always easy to draw lines around features
- Having too many ongoing flagged features can put the system into bad states
As a PM, your goal is to always be receiving feedback from users. Hiding a feature too long can prevent that feedback. Martin Fowler (of all sorts of fame), writes in a post:
“Your first choice should be to break the feature down so you can safely introduce parts of the feature into the product. The advantages of doing this are the same ones as any strategy based on small, frequent releases. You reduce the risk of things going wrong and you get valuable feedback on how users actually use the feature that will improve the enhancements you make later.”
Feature flagging isn’t just for half-completed features, you can enable this for beta programs as well. A specific set of users can see your new features, or you can have it set to be enabled randomly for A/B testing. Don’t forget to include metrics tracking or you won’t know which is better. For an example of taking things a bit too far, see Graham Siener’s post on using feature-flipping for tracking user interest. They played around a bit with RollOut, an open-source framework to jumpstart flagging.
About the Author