Feature Flags: Good, Bad, or Both?

by

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.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|