Feature flags: bad practices

Feature flags are in our DNA now. I don’t remember how we were rolling out complex features before. But this is a pretty advanced technique and one can run into traps.

Let’s go through bad practices and learn something from them.

I cry when feature flags don’t want to die

That’s the biggest managerial mistake I see. Feature flags have to end their life. But sometimes developers are asked to show a certain feature only to a group of users.

Be careful! That might be a trap!

If someone asks you to show a feature to “power users” (e.g. support) or only to users from a certain region (say, only the French market) then there is a high chance that you don’t have a rollout plan.
It’s a sign that your software is missing some general features like roles, user settings, packages/tiers, or something similar.

Don’t use feature flags for stuff like this because you’ll end up with them till the end of the project. Which will add complexity to the codebase and blur the overview of features rollout.

No clear picture of the rollout

It’s important to keep an eye on all flags and their lifecycle. At Phorest we have a few stages for a flag:

• Not activated yet — no one sees it,
• Internal Release — support, onboarding, and sales get familiar with the feature,
• Beta Release — a list of clients, a region or 5% of our userbase,
• Public Release — 100% of our clients,
• To remove from code — some time after Public Release we can remove it from code to simplify the codebase,
• To archive — we remove it completely from the software we use.

If you don’t have a clear overview then it’s easy for a flag to get stuck in the process. Most often, they get stuck after Public Release when everyone opened champagnes and started the celebration.

It’s our job, as developers, to finish the process and reduce the complexity of the codebase. In our case, it happens weeks after complete rollout when we are sure everyone gets the same variation of a flag.

Developers responsible for the whole process

Look back at the previous section. We have 6 stages of the rollout but only 3 of them involve developers. That’s a healthy situation.

A bad practice is to leave feature flags only with the engineering team. That’s a no-no. If you want to truly leverage from Feature Flags you have to have a product or managerial people involved. Otherwise, it’s not going to be a part of the company’s culture. It’s just going to be another dev thing that devs do.

Product Owners' knowledge about features is more holistic! Can we ship it to everyone? Well, do you have all the translations? Do we have articles written for help pages? Is our support aware or we will say “hello! surprise!”? Do salespeople know what they are selling? Are the marketing materials ready? Etc…

Imagine a happy developer having to deal with all of that ⬆️.

Being afraid of code duplication

As developers, we all believe in DRY (Don’t Repeat Yourself) and our IDEs get crazy when they see code duplication. But avoiding duplication is not always desired with feature flags.

By its nature, this is a temporary solution. Flags have to end their life and we need to make some clean-up.

If you see that introducing a flag would create a huge number of if-else statements then consider code duplication. It will be easier to maintain and remove the flag.
Say you have a component.js that does something. If introducing a flag increases the complexity of code significantly then you should rather copy the code and introduce component-v2.js .
At the time you’ll be removing the flag you just have to delete component.js and rename component-v2.js. Much much easier than going through if-else soup.

Not thinking about the removal process

It’s a bit connected with the section above. When you introduce a flag and make the code changes you have all the context about it.
You won’t have it in a few months from now when you’ll be removing it. Neither someone else.

Make yourself a favor and right after introducing a flag, create another PR that removes it. Sure, in a few months you’ll have to rebase it. Maybe resolve some conflicts. But the majority of the work will be done. Some memory anchors will trigger and that will make the process easier.

So raise a flag removal Pull Request when introducing one.

Mixing flag logic with application logic

As you see, code duplication is allowed. The removal process is taken into account. So to complement this way of thinking we must say that mixing flag logic with application logic is a bad practice.

Instead of code like this:

Prefer this:

Yes, it’s more lines of code but so much easier to remove and reason about. We just need to remove one if without analyzing how it’s going to affect the business logic.

Introducing a flag in too many places

You see the pattern, don’t you? It’s all about easy removal as the thing is temporal. Introducing a flag in too many places is a bad practice. You should think a little bit about the right place for a flag that will serve as a gate.

For example, you guard the whole route that is not accessible for people without the flag instead of adding it to almost every component that is on that page.

Adding “disabling” feature flags

Feature flags should always switch the functionality ON. You should not mix the logic here and add flags that switch something off when they are on. It doesn’t make sense when I wrote it down, right? But look at the examples below, it’s quite easy to run into that trap.

Say you add a discounts feature and you want to get the proper price from the resource that holds prices. You could do this, which is bad:

Instead, prefer this — always enabling:

Summary

To summarize, you should have a plan for a feature rollout and how to kill the flag. Make the killing as easy as possible through code duplication, not mixing flags with business logic, raising a PR with removal when you have a context, and thinking what’s the best place for them in your code.

Be afraid when flags are used to cover the lack of functionality in your software. And remember, that’s not a dev thing!

Tomek Nieżurawski writes also on his own blog — tomekdev.com.

We are always looking to speak to amazing engineers about joining the Phorest team. You can check out open roles here.