Skip to main content

Feature Flags Downfalls - Top Mistakes to Avoid

· 6 min read
Marko Benjak
Marko Benjak
It works on my machine.

After using a certain tool, feature, or framework in expanding projects, things will start to look more complicated. You begin to wonder if everything is up to standards. Are things implemented correctly and are we following the best practices at the moment, so we have an easier time in the future? The short answer is probably not, because it's impossible.

Every project is different, and it requires an individual approach which will have to have some shortcuts. That being the case, each tool has a certain set of advice on what not to do. If followed, projects can avoid looming pitfalls.

feature flags downfalls cover photo

Feature flags are an innovative way of feature management. By using it, you can flag the component and easily disable or enable a feature. This can be done without redeploying the application, and it can target specific clients, regions, or any other category needed.

Old and stale flags​

Let's start with the issue the entire development community despises. That being legacy features that are old and unused. The same goes for the feature flags.

Often, especially in large code bases, unnecessary flags are left unattended once the feature has been fully deployed and there is no chance of rollback. Not removing them can lead to the wrong features being turned on/off or even breaking existing functionalities. Remember, flags are used to serve a certain purpose and once that is finished they should be retired and removed. Spending more time than necessary on maintenance is wasted time.

There are certain ways of automating this process:

  1. Set an expiration date for the flags.
  2. Set the time in the developer's calendar each month or two for a review of existing flags.

Pro tip: ConfigCat has a smart solution that can help in the fight against the stale flags with The Zombie Feature Flags Report.

Reusing old feature flags​

One other thing worth mentioning when it comes to maintenance is not having a proper naming convention and reusing the flag's names. This usually happens when developers are naming flags as they please or rewrite them because they do not have time for creating new ones.

The solution is to adopt a naming convention and give the flags distinctive names which are describing what is the purpose of the flag. For example, ConfigCat uses "camelCase", but other options which are viable depending on the team's internal agreement are:

  • snake_case
  • PascalCase
  • kebab-case

By doing so, you are mitigating the risk of reusing the same flag and rewriting its purpose while it is still active. It also improves readability and lowers the time spent trying to understand what the flag does, while it does not increase technical debt. The most important thing here is to stick with the choice and to always apply it.

Consumer-facing feature flags​

When the need comes for the feature flag on the UI components of your application, ensure that you are using another flag for your connected backend code, of course, if there is any backend code connected to the frontend feature. Both flags should be connected, and they need to depend on each other. If one is not activated the other will not be as well.

The best example here would be a button or trigger which sends an API request. Having a backend feature flag ensures there is no way of using the frontend feature until they are both enabled. If this is done correctly, forgetting to release one part of the implementation would not be such a big deal since it would be disabled by default.

Not planning the release properly​

With a growing business comes a different type of clientele. A good release plan created by the release manager will rank clients by the risk factor they present. In this case, low-risk clients will be getting the feature first. This type of release is called the Phased Release or Canary Release.

Canary Releases rollout software in phases. In each phase the new software version is released to a few systems, either chosen randomly or chosen by the risk factor they present (low risk comes first). As soon as the version is out, the system is monitored and upon satisfying the quality goals, a new phase can begin. Usually, everything is done within the week, because waiting any longer could lead to unwanted problems and version jumping.

Not prioritizing perfect code with the planned release over the speedy delivery could lead to a lot of technical debt. Once it is accumulated it will have to be paid with the refactoring of the code and with a lot of hours wasted on something which could have been done correctly in the first place.

Keeping the connection strings​

There should not be too much of an introduction here. Keeping the connection strings (which are confidential data) in feature flags, especially in the frontend is not recommended, due to the security risk they present. Keeping the connection data in the config store will not allow unwanted accessibility to outer systems.

Consider not doing​

Having eliminated all the above from your codebase, consider some other things:

  • Storing a complete JSON in a feature flag. This will make it hard to read and maintain. If such a situation arises, JSON should be divided into smaller feature flags. And do not forget to give those flags distinctive names which will connect them.

  • Having a feature flag on the frontend. This was already mentioned in the post, and now it should get a bit more context. When a flag is used on a frontend it is downloaded by the browser during the loading phase. This means it can be accessed by the user of the browser and features can potentially be turned on or off.

  • Try to use backend endpoints. If it is necessary to use a frontend flag it is recommended to use a targeting feature called confidential text comparators which will hide sensitive data in targeting rules.

To sum it up​

Having feature flags active in a code base is a great thing. They will simplify feature rollout and continuous delivery and protect the clients in the long run from unwanted mistakes. However, they do suffer from similar problems as every other tool used by teams to develop and run an application. Those are either human mistakes and laziness or security loopholes.

Like with anything, they are prone to misuse if not maintained and taken care of properly. But with a few simple rules covered in this post, they can be kept in order without much of a headache.

And remember, if you want to learn more about the feature flags or stay up to date with all the news, check out the ConfigCat social hub: