Five mistakes teams make with feature flags

Most teams know this matters. Fewer have decided who owns it. These are the ones we run into repeatedly when we audit feature flags.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Common failure modes

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Flags let you ship code before you ship the feature
• Rolling out to a small group first contains the blast radius
• Never checking whether the fix actually worked

Delete flags once they are permanently on. That sounds obvious written down. It is still the thing most often skipped. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

What to do next

In practice

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
• Delete flags once they are permanently on — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.