I’ve got a static analysis/garbage collector type problem involving feature flags, multiple code repos, and services. I’m wondering if it has a name and optimal strategy towards solving it. There are hundreds of flags that seem like they are defined in constants file but never accessed. I can’t simply delete flags that are unused in one project because they might be passed to a second project via an endpoint. In order to “garbage collect” the “unused” flags I need to find the ones that are only defined in constant files across the system. (This is screaming set theory as I type it out 🦆 ) Has anyone encountered a problem like this and have a strategy for solving?

I haven't solved it personally, but it sounds very much like the kind of thing I hear split.io talk about all the time. So absent another option, I would check out some of their materials to see if it gives direction?

Thank you, I will check them out!

Split.io , launchdarkly and all the others have solutions which are based on the fact that apps using their SDKs report usage back (on each rule/flag evaluation) Assuming your services/apps use the SDKs, and register themselves correctly, it shouldn't be a problem to generate a report on flag usage by application - and figure out if and when they are used. This is an essential part IMO of a feature flag service, along with a host of other things like HA, local dev environment support (for testing) and more. Reading your question again, it seems that you share values between apps (meaning the receiving app doesn't report usage probably - so it won't be as simple). In that case I would implement some metrics where I can to track usage, count if and when code block protected by the flag - this is what we did before central flag services where a thing ...

@Moshe Eshel - you hit the nail on the head!

, it seems that you share values between apps (meaning the receiving app doesn’t report usage probably - so it won’t be as simple).

Even worse, the back-end service is blindly caching everything for the front ends. I’m using

LaunchDarkly

in this case, but all my metrics are “used all the time” because of the back end cacher

That's the only way to go sadly, but I do suggest as long as you're at it and actively touching the code to add usage metrics to the ones that are active, so at a later date it will be a simple dashboard that you can check to find those that still have a reference but not actually used. Much more effective than log crawling with grep (and you're always worried about missing a file/reference and breaking something) Next step is to move the front end to query the flags directly, all these platforms now offer dedicated read-only front end APIs , exactly for these purposes (or you can easily write your own proxy for same).