Hacker News new | ask | show | jobs
by svieira 1775 days ago
Testing base, stable (from my perspective) infrastructure? Should I have tests that validate that JPGs still render? How about when used as a CSS background image? Does Chrome test the register reads assembly code produced by the C++ compiler in case there's a breaking change that gets missed?
1 comments

I don't mean to hammer this point too hard, but when Chrome released click-to-play breaking changes for web audio, they broke alarms/timers on Google search.

So the "you'd catch all these changes if you were testing" excuse honestly kind of rubs me the wrong way, because as far as I can tell Google itself has trouble meeting that standard for even its biggest products.

Bugs happen, it's part of software development and no one is claiming any products from any company are exempt from them. We're only humans and it's still mostly humans writing the tests.

But the bigger story is not about solving specific bugs but how to learn from them, to make sure they don't happen in the future. It's not about putting the blame on specific individual or teams for their insufficient communication or testing.

> It's not about putting the blame on specific individual or teams for their insufficient communication or testing.

We don't need to put the blame on anyone, but to your point on learning from bugs and making sure they don't happen in the future, how can that happen if we're fatalistic about why those bugs were caused?

I don't know what the Chrome team is doing differently now to prevent another situation like web audio from happening, because there was never any followup about process changes. The only thing that we were ever told during the web audio failure was that we needed to trust the Chrome team, and that they cared. But that never turned into anything tangible or visible. And X years later and X broken feature launches later, we're still having the same conversation.

If avoiding blame means we can't talk about why something went wrong, then that's a broken process. You're telling me that reaching out to developers is futile, and unless we pay a ton of attention to the mailing lists we're going to miss stuff, and that testing is the only thing that can save us. That's a regression from what I heard from Chrome devs during the web audio debacle. The team seems to have gotten more insular, not less.

We don't need to assign blame, but it would be good to actually learn from these situations. Nothing is changing, the dysfunctional communication between the Chrome dev team and developers is still just as bad today as it has ever been. Is the Chrome team going to do anything at all to help make the situation better?