Technical debt can arise from many places and 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 either be made visible or not to a user depending on whether it is switched on or off. Simply put, a feature flag can be turned on/off independent of deployment.
But 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 examples of feature flag use gone wrong:
Number 1: if a feature flag has an vague/unclear name - it is ripe for causing complications down the line. A flag that is called "user_control" might be thought by one backend team to controlled a given piece of functionality that they wanted off for a release, while another team thought 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 was time, energy, and resources wasted due to a lack of foresight from the original person responsible for labeling the flag and made it difficult for developers to do what initially had been a simple task.
Number 2: the improper or delayed removal of a flag can also be a source of dysfunction in development.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 flags, are turned on. So 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 by removing these inactive flags.
Number 3: if you are using flags to control functionality you are creating multiple levels within your system. Just as we pointed out in our first mis-use of function flags, 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. But asides from the problem of mislabeled flags, it is necessary that teams coordinate between each other to know if they are even using flags. If a technical team runs all its integration tests against another teams and passed all of them thinking everything was fine - 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 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 you take a look at the feature flags in your code base and evaluate whether their adding value or just adding onto its complexity.
To read more visit here.