Your proposed process is exactly the wrong way around. You'll end up keeping dead code just because it has tests, and delete code that's still used in prod just because it happened to be untested.

This is one of the details that the blog post goes into. Sounds like it's not as trivial and obvious a problem as you think it is, and you would have benefited from just not dismissing the post because of that.

Not to criticize your POV and argument directly, but, in the end, a lot of things, especially like these, are always easily subjected to the "we could do it, but just didn't bother to yet" kind of argument, and, when it comes down to the real work, things are much harder than they superficially appear to be. So yeah this isn't new... But... You know eheh

Well, I'd politely agree to disagree. Google scale is defined by novel, radical approaches, like for example inventing map/reduce, writing papers on LLMs others then implement successfully, or creating something like Kubernetes.

The specific topic here is not one of those google problems to me, as I can compare it to other problems we already solved. But yes, we could miss that critical point where a totally different problem domain emerges just from one order of magnitude more, so fair game.

Thanks for the reply and I meant it from similar experiences at my $DAYJOB where any initiative like this always uncovers a lot of dusty corners! Thanks for the great and polite reply, it's rare nowadays, so kudos!

I think the takeaway is that at Google's scale, even if you think some minor problem is not pressing enough to be automated, it will become pressing soon enough.