For one, that "deprioritize a competitor" is not clear at all. Why would that be so? Isn't it far more likely, given the rarity of these events, that a test regression occurred or some other subtle issue rather than assumed malfeasance?

For two, that "next update in 12 hours" is user comms. For me, at least, google.com works fine both on curl and my browser. That's a fairly normal cadence for big companies.

On the larger point about "nimble and deploying rapidly", the people who generally brag about "being nimble and deploying rapidly" almost never serve an even 1/100th the audience the size of Google.com does, and it's really questionable if, at that scale, you actually want to risk global regressions even on trivial bugs.

So I don't know what that user is talking about, and I agree with you that they are obviously not that.

That approach may be antithetical to the modern startup engineer frantic to prove their stock's hypothetical worth to their investors, unconcerned about trivial revenue loss from frontpage issues because of whatever latest node.js drama nuked their continuously deployed website. But the fact that "the landing search page is broken for 1% of users in a rare but public use case" is news at all is because Google's approach for search sets our expectations that this won't happen.

Only way to really test that is to break search for chrome and see how long that takes to rollback.

Nimble is on the order of a week, not on the order of hours at their scale.

But it's also not on the order of quarters, is what I mean.

It is gated on a lot of things, especially relative to early days of the company. It's just that browser compatibility isn't generally one of those things... They still handle that by the belief they can roll back quickly.

Relatively speaking, you can still undo the change to the front page faster than you can, say, roll out a new version of a desktop application, especially if the change fixes an active fire.