Feature Flags Are Ruining Your Codebase
Feature Flags are a commonly used technique when releasing new features. They allow us to quickly turn specific features on or off, such as in the following Python code example, where you can switch between the new and old payment services through configuration settings:
USE_NEW_PAYMENT_SERVICE = config.get('NEW_PAYMENT_SERVICE') is True
if USE_NEW_PAYMENT_SERVICE:
...(the new logic)
else:
...(the old logic)
While Feature Flags are convenient, they also bring many issues that we should be aware of or may have experienced ourselves. Unlike the author of “Feature flags are ruining your codebase,” most of us haven’t organized the pros and cons of Feature Flags so clearly. I recommend spending some time reading that article, as it not only brings up many relatable points but also shows how to improve in the future.
Here’s my summary:
- Feature Flags are indeed useful, but they should be seen as a last resort. If a feature should go live or be removed, proceed with that action bravely instead of using Feature Flags to allow PMs to switch it on or off at any time. PMs might develop a liking for this flexibility and start pushing all sorts of experimental ideas into the production environment, even making the ideation, research, and verification processes hasty. This happens because, for PMs, bringing features online or offline becomes a low-cost affair, ignoring the cost others have to bear. These costs include developers integrating Feature Flags into the code, which could double the logic in simple cases or multiply it in complex ones. Worse, there might be interactions between Feature Flags. For example, if Flags A and B each have two states, they could generate four (2x2) different logic scenarios, increasing the workload for testers as more cases need checking.
- Feature Flags can complicate future maintenance of the codebase. From personal experience, after Feature Flags are deployed, few people pay attention to their status. As a result, the code retains these Flags long after the reasons for their existence have faded from memory. When maintenance or upgrades are needed, an unlucky person becomes the code archaeologist, trying to dig through old documents, PMs, and developers to understand the original intent and determine the next steps. Often, this process doesn’t go smoothly, and people decide to keep the Feature Flags until the next unfortunate person faces the same dilemma.
Possible solutions include:
- Set a limit on the number of Feature Flags a system can accommodate at once. If the number exceeds this threshold, make tests fail intentionally to force attention to the issue (provided the team agrees to this approach).
- Assign a reasonable expiration time for each Feature Flag. If a Flag reaches its expiry without action, let tests fail to prompt the removal of unnecessary Flags.
- Every developer or PM responsible for creating a Feature Flag should track it with a ticket, ensuring everyone understands that Feature Flags carry a cost and use them cautiously.
In conclusion, every time you consider using a Feature Flag, ask yourself, “Is it really necessary?”