DEV Community

Discussion on: Feature Flags Simply Explained 🎥[video]

Collapse
 
n3wt0n profile image
Davide 'CoderDave' Benvegnù

Hey, those are good questions.

Do you think the use of feature flags is too invasive and may affect the normal operation of the program?

FF shouldn't be invasive, and should not affect the normal operations. Of course, they need to be used wisely and cleaned up every once in a while to remove the ones that are not neccessary anymore (for example, already turned ON and with no paln to roll them back OFF) and the related code. A good practice for this is having a "shared calendar" in your ALM tool in which every developer can see which FF are currently added to the software, and when to remove them (of course it should be keep up-to-date), and make that as part as your sprint as well

What do you think about Launchdarkly's Code reference feature?

I've actually never used it, so I cannot talk "by experience", but it seems ok. Useful to keep track of your FF in a semi-automated way

Would a code analysis tool to help solve unexpected failures caused by Feature flag be useful?

Not sure about what you mean by unexpected failures caused by Feature flag but I don't think any code analysis tool have an out-of-the-box feature fot this (at least, I've never seen one personally, I may be wrong). FFF should not cause any unexpected failure per se, a good FF management system and implementation should always have a fallback strategy. For example, if you rely on a 3rd party system for evaluating the status of your FF, like App Config or LaunchDarkly, you should design your FF to be able to evaluate to a default state (either on or off) in case your software is unable to reach said service