A TL I worked with once had a simple but effective strategy for that:

"Remove it and see who complains."

I did that (with the impenetrably named "PrefetchExperiment", last touched by a branch that lost previous file history in 2007). Turned out it was the source data for Google's DNS to figure out how to route queries to the lowest-latency datacenter, based on their geographic location. In about a month, it would've taken down all Google services. Oops.

It was a very effective way of figuring out who owned the variable and writing a big long comment explaining what it's there for and which team to contact before changing it, though.

The hilarious thing is I know exactly what file you're talking about here.

LMAO, isn't this very similar to FaceBook's recent DNS problem?

Also I love the idea of removing it and seeing who complains.

Facebook's recent "DNS problem" was a process for checking routing failover capacity on the backbone for maintenance ended up taking down the backbone links. As a result of the servers being disconnected from the backbone they pulled their BGP advertisements since they considered their location to be unhealthy (no connection to the backbone).

FB's problem was the lack of routing reachability on its backbone triggering the lack of routing reachability information being sent to the larger internet, this in turn caused problems for DNS not the other way around.

It also works great for a product / bug backlog. Just delete the entire thing. If it's a real bug / feature it will get recreated.

Scream tests are always fun. ("break it and see who screams")

The best and worst parts of being a Google engineer: Impossible things are merely very hard, but on the other hand, easy things are also very hard.