In service oriented architectures adding new application settings like environment variables, constants, and feature flags costs almost nothing.  Cleaning them up, however, is expensive.  

Ideally developers would keep track of settings and remove them when they are no longer needed.  More often feature flags get set to 100%, everyone moves on, and the old code path lingers for months.  I have personally spent hours updating code, only to realize that it is effectively unreachable and needs to be deleted instead.

Talk about wasting time and money!

The High Cost of Doing Nothing

Doing nothing seems like a cheap solution.  The code gets a little bloated, the services use a little more memory, and API calls send a few extra kilobytes.  No single unused feature flag or environment variable has any impact.

Eventually you end up with hundreds of unused settings, on thousands of servers, distributed to hundreds of thousands of customers.  

The cost of those crufty settings add up in terms of performance, development time, and outages.

Cutting Cruft Is Expensive Too

A key disadvantage of Service Oriented Architecture is that settings get passed from one service to the next.  It’s rarely safe to remove unused settings because they may be gathered into a collection and passed along to a service that does use them.

Figuring out what is used where across multiple services is a slow process.  When you’ve got hundreds of settings to investigate, it’s daunting and demoralizing.

A Very Basic Garbage Collector

A Garbage Collector keeps track of references to objects, and when there are no more references, cleans them up.

You can make a very basic collector by scripting out a few API calls to your git repository.

The three basic steps are:

1. Download and parse the constants file(s) from the parent app and extract a list of settings names
2. Make API requests against your git vendor searching for the strings
3. For each setting name make a file which lists which repo the string appears in

That’s it!  You now have a rudimentary system that tracks references to settings across your repos.  Any setting file with only one entry isn’t used anywhere else and can be deleted once the parent app is done with it.

Conclusion

A garbage collector is overkill if you’re curious about a handful of settings, just use regular search.  But when you’re facing hundreds of settings and you need to figure out which can be targeted for cleanup, a garbage collector might be just what you need.