Technical debt can arise from many places. Today, we will focus on poorly used and created feature flags. When used correctly, feature flags can greatly aid development by separating out software releases. A feature that is live in production can be made either visible or not visible to a user depending on whether it is switched on or off. Simply put, a feature flag can be turned on or off independently of deployment.
However, feature flags can be complex, as well, depending on what is needed for release deployment or long-term controls (like behavioral or access level control). While there is good that feature flags can bring to the development process, they can also create extremely damaging technical debt if misused.
These are few incidences in which feature flag use can go wrong.
If a Feature Flag Has a Vague or Unclear Name
In this case, a feature flag will be ripe for causing complications down the line. A flag that is called user_control might be thought by one backend team to control a given piece of functionality that they wanted off for a release, while another team might have thought that the flag was responsible for another functionality and wanted it on. Each team could be flipping the flag on and off for quite some time before realizing where the confusion stemmed from and separating out the flag. This means time, energy, and resources wasted due to a lack of foresight from the original person responsible for labeling the flag and making it difficult for developers to do what initially had been a simple task.
If a Feature Flag Removal is Improper or Delayed
Flags can be used for both long-term and short-term control. A long-term flag is used to permanently control a section of code, for example, to segment the user base (beginner users vs. advanced users). A short-term flag is obviously meant to be temporary and should be removed as soon as it has served its purpose. If this is not done, it can lead to a product being unusable when all flags (both long-term and short-term) are turned on. How do you get around this? We can circle back to properly naming your flags to not just describe what they are for, but whether they are temporary or permanent. It is also important to go through old flags and see whether they still serve a purpose. If they are no longer necessary, it can be extremely helpful to simplify code and remove these inactive flags.
If a Feature Flag Is Creating Multiple Levels Within Your System
When you use a feature flag to control functionality, it creates multiple levels within your system. Just as we pointed out above, that means making sure that front-end and back-end teams are in synch with what levels of a system exist. If you have vaguely named flags, it will be difficult to do so. Aside from the problem of mislabeled flags, it is necessary that teams coordinate with each other to know if they are even using flags. If a technical team runs all of its integration tests against another team's and passes all of them thinking everything is fine, then they could release only to find that the other team had a feature flag for migration that, when flipped, caused their code to break. Problems like this can be avoided, and when they aren’t, they waste time and lead to unneeded complexity within code.
Ultimately, you want to be making a quality software offering and to be able to do this quickly and with predictability. This can be done with the help of feature flags, but as we outlined above, feature flags can go from being a helpful tool to something that simply adds to your technical debt and slows down your development process. It might be time for you to take a look at the feature flags in your code base and evaluate whether their adding value or just adding onto its complexity.