Feature Flagging: The Flagship Idea of Programmers

Introduction

Nowadays, users are more conscious and tech-aware. It means they know what they want, they know how it should be, and if it is not done correctly or meets their criteria, they will look for alternatives. This adds additional pressure on tech companies and developers.

For this reason, when adopting the agile methodology, your work is split into sprints, and at the end of each sprint, the feature on which you worked should be ready to ship.

With the rise of the Agile mindset/methodology and the need to release new features more often, However, there is a catch. Huge features are often broken into smaller components or sub-features [also referred to as stepwise refinement]. For example, in a banking app feature, a user has the option to make payments. But there are multiple scenarios like edge cases, meaning that we should have screens for error messages when there is a failure and happy flow, that is, if the payment is made without any error.

Commonly, the payment feature is separated into at least two tasks, and each one can be tackled in either different sprints or by different developers. This could sometimes result in the main feature not being fully completed at the end of a sprint but only one of the two tasks is completed.

In such cases, the feature can be released to production but is not accessible to the users until it is fully developed and tested. To do so, the feature is disabled based on a condition of a boolean, for example, ifPaymentReady == false. It is said that the feature is toggled off, and when ready, the boolean or flag is turned on, and the users can see that feature.

In this article, we will see the advantages of feature flagging compared to the traditional way of doing deployment, some tools/methods to achieve this, and some considerations.

How is Feature flagging used?

Traditionally, we work on a feature for months and test it for weeks, and when we are sure it is safe to deploy, we proceed with the deployment.

Unfortunately, releasing a new feature to your customers takes a lot of time.

If you do not have some kind of feature flagging mechanism, you would need to implement one yourself. Some developers either use config files and environment files or build a feature flagging system custom for their project.

The issue is that you need to maintain everything yourself and spend time developing it.

How do feature flags ease releases?

When using feature flagging, the way we release new features changes.

You continuously develop, test, and deploy new codes. With the help of a feature flag, the unfinished feature is toggled off, meaning that it is not visible to users, and hence they cannot use it.

Once you are done with the whole feature and you are sure it works correctly, you can just toggle it on, and users can start using it. This is when you can officially say that the new feature is released.

Nowadays, feature flagging has become so important that there are several tools available, and you can just use them. This removes the burden of having to create, manage, and maintain the feature flagging mechanism yourself.

Advantages of feature flags

1. Features can be toggled on or off at runtime. There is no need to rebuild and redeploy just to change the status of a feature. The moment you toggle the feature, the change should be visible without any additional action.
2. Ease debug control
   It can happen that when you have just released a feature, some bugs can still occur. To minimize the effect of the bug, you can easily toggle the feature off.
   Once all the issues have been resolved, you can re-enable it
3. Improves deployment frequency.
   You can continuously deploy new codes even for unfinished features; just ensure it does not break your whole app. Have a feature flag for this feature and toggle it off. In this way, part of the feature is continuously deployed, and once it is all good, you can switch it on.
   This is aligned with the Agile methodology, which is when you continuously ship new code to production.

 Best Practices

1. Use meaningful names: When naming variables, strict conventions must be followed. Having a meaningful name helps us easily identify which feature uses which flag. This makes it more maintainable and professional.
2. Delete old flags: As projects grow bigger, we will have more and more flags. When a feature is live and working correctly, there is no need to have a flag, as it will be a dead code. This results in technical debt.
3. Do not reuse flags: As mentioned earlier, it is essential to have flags with meaningful names and to delete old flags. However, some people can be tempted to reuse old flags so they do not have to delete them for maintainability reasons. This is a bad practice. Old flags should be deleted and create new ones for new features.
4. Limit the scope of the flag: A flag impacting your code in more than one place makes it difficult to predict its impact on the code and its behavior.

A common practice is to use feature flags at entry points. One example is the feature flagging an option in a navigation. Toggling off an event in the navigation prevents de facto users from having access to the feature and using it. There is no need to go further in the implementation of that feature and further add the flags there.

Conclusion

Feature flagging is a powerful concept that helps companies release value quickly and efficiently. If done correctly, the benefits are almost instantaneous. Like all things, here are guidelines to be followed.

In this article, we have seen what feature flags are, their advantages, and their considerations. I hope that this will help you to better architect your project, as feature flagging is something that should be thought of during the planning phase of any project but can also be picked up later.