The key point here is "... and hardly anyone noticed."
In theory, site reliability engineers and software engineers work together at Google to maintain existing functionality and check for regressions. In practice, regression checks can only cover what they've been told to cover, and if breaking a feature doesn't cause a metric to crash, Site Reliability doesn't have the information to know something is wrong.
The result is that generally speaking, Google prioritizes existing features by how popular they are (i.e. "Maintenance by Popularity") modulo how much of a stink someone influential can make if they screw it up (i.e. "Maintenance by Twitter."). If almost nobody uses the CC filter (and I bet, in the grand scheme of things, they don't), Google may not have enough signal to know they broke the filter unless someone had the foresight to add a metric to check search results on that query separate from the rest of the search result data (and at Google's scale, you can't just add a metric for free; in addition to eng-hours to build and tune it, the data has to be stored somewhere and teams have finite budgets for space that can only be grown by negotiation with the relevant teams managing the monitoring services or the project as a whole).
...or they screw it up, make it worse and worse, and less and less people use it, making it less popular, less chance someone fixes it, less people use it, less chance, less people, less, less, google graveyard.
Both google image search and "normal" google search are becoming more and more a pain to use, where you have to use quotemarks on pretty much everything plus a few excludes to find anything at all.
Yep. This is definitely the flip-side of Google's process.
It makes some sense; take a step back, and the story is "If Google software engineers don't care enough to make it good, and Google users don't care enough to keep using it in spite of its flaws, why is Google throwing money at it at all?"
Google is a weird company because so many priorities are set by software engineers, not managers; some projects die because they literally run out of passionate engineers to work on them and management isn't incentivized to force engineers to work on projects they hate, instead asking the question "If nobody wants to work on this, is it worth it to keep doing it?"
I mean... on the other hand, managers like to bring out some shiny new projects... noone gets praise for "we continued supporting this project..." at quarterly and yearly meetings.
Atleast I think so... what else can explain so many chat platforms that came out of google and died soon after?
In theory, site reliability engineers and software engineers work together at Google to maintain existing functionality and check for regressions. In practice, regression checks can only cover what they've been told to cover, and if breaking a feature doesn't cause a metric to crash, Site Reliability doesn't have the information to know something is wrong.
The result is that generally speaking, Google prioritizes existing features by how popular they are (i.e. "Maintenance by Popularity") modulo how much of a stink someone influential can make if they screw it up (i.e. "Maintenance by Twitter."). If almost nobody uses the CC filter (and I bet, in the grand scheme of things, they don't), Google may not have enough signal to know they broke the filter unless someone had the foresight to add a metric to check search results on that query separate from the rest of the search result data (and at Google's scale, you can't just add a metric for free; in addition to eng-hours to build and tune it, the data has to be stored somewhere and teams have finite budgets for space that can only be grown by negotiation with the relevant teams managing the monitoring services or the project as a whole).