A practical checklist for feature flags

Most teams know this matters. Fewer have decided who owns it. Run through this the next time feature flags comes up.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. The version that survives contact with a real deadline is the simple one.

The checklist

• Flags let you ship code before you ship the feature
• Rolling out to a small group first contains the blast radius
• Delete flags once they are permanently on
• Someone is named as the owner
• There is a date to review it again

The reason this keeps coming up

Flags let you ship code before you ship the feature. The reasoning matters more than the rule, because the rule has exceptions. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

How to tell if yours is fine

Most development decisions are really maintenance decisions wearing a different hat. Three things worth confirming about feature flags before you move on:

• Someone can say what the current setup is without going to look
• Rolling out to a small group first contains the blast radius — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.