Some of us learn best when we’re taught the right way to do things, and it works out easily and well. And some of us learn best from watching horrible things happen and deciding that we’re not going to do that. It’s the theory behind scary driver’s education videos and TikTok challenges gone amiss.
I want to offer you some mistakes that people really have made in their feature flag journey, so maybe you don’t have to make them yourself.
1. The word “and” was your first mistake
A feature flag should do only one thing at a time. Even if your targeting may be split several ways, the flag itself only turns the targeting on and off. If you are describing what the flag does, and you use the word “and,” I promise that at some point in the future, you will have a regret. Making multi-function flags, instead of multiple, one-function flags, means that you or the next person to use it will not entirely understand the function, effect, or targeting of that flag.
2. Foobar, the name that launched 1,000 slips
Naming things is hard. This is a truth known to parents and startup founders alike. When you are trying to think through the structure of a flag and how it works, it’s really tempting to use a placeholder, like you might in code development. Resist the urge!
Give your flag a name that actually describes what is being affected. “Dark mode” or “Inbound gateway” are going to be a lot more useful than “SporkTestFlag.” Relatedly, it seems logical to name a flag “Tiles on,” to indicate that the flag controls whether the flags are on… but it turns out to be confusing. If you turn the “Tiles on” flag on for some people, but exclude a targeted group, does that mean that they have “Flags on” off? Or is it on but not targeted at them? You can see how it would get complicated.
3. Division of responsibility? Sounds corporate
Just because someone put a feature flag into code, that means they own its operation forever, right? Wrong. The beauty of putting a control point in your product is that you don’t need a developer to change the code’s behavior. Instead, you can move that power to the place with the most information, like product management or even technical support. This division of responsibility also allows you to have a division of time, so a developer doesn’t have to revisit features that are already fair in their rearview mirror.
4. Feature flags? Ops’ problem now!
The division of responsibility can backfire, if it means that all of the feature management becomes another responsibility for your operations, DevOps, or SRE teams. Although it’s great to democratize who can power feature flags, it’s not a great idea to hand their operation off to a team that doesn’t understand the context of their value. When you are using feature flags, it’s important to remember that context matters to every stage of feature management.
5. Technical debt (or the Chest Freezer Problem)
In modern software development, we don’t have to think about space constraints very often. It’s like having a chest freezer—extra veggies? Put them in the freezer. We sometimes handle flags in the same way—just put it in, it’ll be fine, we don’t need to worry about it. But every time we leave a temporary flag in, we’re adding to the technical debt in our project. If we keep doing that, we don’t have room for new things and we can only get to a few layers of the older stuff. Because temporary flags weren’t meant or built to last, they are just sitting there getting freezer-burned. And if anything goes wrong, it’s all going to smell real bad.
6. That was a load-bearing flag
We often think of feature flags as ephemeral. They're useful for safe deployments or experimentation, but have a time-limit on how long they're going to be useful, and then we would ideally pull the flags out of the code. But some flags are intended to be long-lived or permanent—things that will always be a part of the code base and allow us to alter the way the program works. This might include user entitlements, operations circuit breakers, or other flags that are part of the way the software works.
7. Recycle beer cans, not feature flags or band-aids
You wouldn’t re-use a bandaid, would you? Don’t re-use a feature flag, either. In fact, flag re-use is the source of our most notable feature flag horror story, Knight Capital. But even leaving aside that catastrophic case, re-using a flag is bad policy because that's not what it is designed for. Are you sure that the targeting and action are exactly the same? Are you sure that if you change an existing flag, you won’t be affecting the behavior for other users who were on the old flag?
Don’t foul up!
These are just some of the many ways it’s possible to use feature flags in a regrettable way. I hope that this makes it feel a little safer to use feature flags, since almost none of the failure modes are surprising.
Get a quick-and-easy guide to feature flags with our ebook, "30 Feature Flagging Best Practices Mega Guide."
