Feature flags are easy to add and hard to remove. That asymmetry is where the trouble starts.
Used properly, feature flags give you safer deployments, gradual rollouts, and emergency kill switches. Used poorly, they turn your codebase into a haunted house full of dead branches nobody dares to touch.
Here are some of the most common ways feature flags go wrong.
Zombie Flags
A zombie flag is a flag that should have been deleted months ago but wasn't.
The feature shipped. The experiment ended. Everyone moved on. But the flag?
Still there.
Nobody remembers what it does, why it exists, or whether removing it will summon Cthulhu.
Zombie flags accumulate over time. Eventually your codebase is full of if statements that will never execute, conditions that are always true, and dead code paths nobody has tested in years.
It's technical debt with extra steps.
The fix
Treat flag cleanup as part of the feature work. When you create a flag, decide when it should go away. Put the removal task in the ticket. Assign an owner. Set a reminder. Do whatever it takes.
Don't let flags outlive their purpose.
Flag Explosion
One flag? Fine.
Ten flags? Manageable.
Fifty flags?
Better start looking for that spreadsheet.
A hundred flags?
Congratulations. You have more feature flags than features.
Flag explosion happens when teams add flags without a policy for removing them. Every new feature gets a flag "just in case," and somehow "just in case" becomes "forever."
Now every deployment requires checking a giant configuration table before you can figure out what users are actually going to see.
The fix
Keep track of:
- What each flag does
- Who owns it
- Why it exists
- When it should be removed
If a flag has no owner and no expiration plan, it's already a zombie waiting to happen.
Or, instead of maintaining yet another spreadsheet that everyone forgets exists, use a feature flag management tool that tracks this stuff for you.
Because the spreadsheet you create at 2pm is definitely going to be updated when you're shipping at midnight.
Right?
Testing Complexity
Here's where feature flags get mathematically unpleasant.
Every binary feature flag can double the number of possible states your application can be in.
Two flags?
4 combinations.
Ten flags?
1,024 combinations.
Twenty flags?
1,048,576 combinations.
You probably don't have time to test all of those.
Neither does your QA team.
In practice, not every combination matters. But eventually you'll hit one that does, and you'll probably discover it when a user finds the exact combination you didn't test.
The fix
Minimize the number of active flags.
Retire old flags aggressively.
Don't let temporary rollout flags become permanent application architecture.
The longer a flag sticks around, the more combinations you have to reason about.
Missing Documentation
"What does
EnableSuperModedo?"
"No idea. Don't touch it."
This conversation happens at every company that uses feature flags without documenting them. The original developer left. The ticket was closed. The Slack thread disappeared into the void. And now everyone is terrified to remove the flag because nobody knows what happens when you flip it.
Every flag should have:
- A name that explains what it does
- A description of why it exists
- An owner
- A plan for when it should be removed
If you can't explain a flag in one sentence, it's probably not ready to ship.
The Bottom Line
Feature flags are powerful. But power comes with responsibility, blah blah blah. The important part is:
Add them intentionally.
Document them thoroughly.
Remove them ruthlessly.
Feature flags should make your codebase easier to operate, not turn it into an archaeological dig.
If you're managing more than a handful of flags, a dedicated flag management tool can help you keep track of what's active, who owns it, and what needs to be cleaned up.
Try FeatureFlags.app and stop letting your feature flags become zombies.
The only good zombie flag is a deleted one.
Top comments (0)