3 ms·

As a friend of mine explained why she left Google a year or so ago, "I got tired of emailing 30 people to try to figure out who owned a single variable."

raldi 5y ago
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.
nostrademons 5y ago
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.
- joshuamorton 5y ago
  Scream tests are always fun. ("break it and see who screams")
- ikiris 5y ago
  The hilarious thing is I know exactly what file you're talking about here.
- AlexanderTheGr8 5y ago
  LMAO, isn't this very similar to FaceBook's recent DNS problem? Also I love the idea of removing it and seeing who complains.
  - _3u10 5y ago
    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.
  - zamadatix 5y ago
    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.

raldi 5y ago

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.

nostrademons 5y ago

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.

joshuamorton 5y ago
Scream tests are always fun. ("break it and see who screams")
ikiris 5y ago
The hilarious thing is I know exactly what file you're talking about here.
AlexanderTheGr8 5y ago
LMAO, isn't this very similar to FaceBook's recent DNS problem? Also I love the idea of removing it and seeing who complains.
- _3u10 5y ago
  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.
- zamadatix 5y ago
  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.