Interesting thread... but I really doubt the oopses were intentional. Instead it's just a case of nih syndrome, where the engineers have a myopic view and only test/build for the internal Google infra and apps. The same thing happens in golang and Kubernetes.
It doesn't matter if they were intentional. The author mentioned there may hav been hundreds of these "oops" events. Assuming it wasn't intentional, Google knew there was a problem and chose not to fix it.
"Fool me once, shame on you. Fool me twice, shame on me."
Or in Google's case, "fool Mozilla a hundred times..."
This is semantics - he's saying that the individual "oopses" were accidental, but you're saying the overall strategy of neglecting Firefox support was intentional. This jells with what others here have said about individual googlers vs. executive leadership / emergent organizational behavior.
If YouTube developers are pushing changes that break IE6 layout for the "hundredth time" or crash the browser or OS, it sounds like they didn't have adequate QA or didn't test IE6, even though it was used by 18% of their users. "Nobody joining the team could be expected to know that early versions of IE" had some quirk could be caught by code reviews and QA.
If you worked on web software at that time, 50% of the work was making something that worked in every other browser, then the next 50% was making it work in IE6 without breaking everything else. The arrival of IE8, while it was less awful than IE6, made things worse because many of the hacks used to make things IE6 friendly, worked with IE8, so the collection of stupid CSS hacks one had to memorize grew even more complex.
IE6 was a browser of the same era as Netscape 4, when it was common and unsurprising for a CSS error or a malformed bit of HTML to crash the browser.
It really is hard to describe how much bullshit devs have had to put up with to keep IE happy. Even today our front end team wants to use some modern JavaScript features which work fine in everything but IE. IE will never get another upgrade but it’s still holding tight to that small install base.
Yeah, I worked on a much smaller product and we aggressively ran automated selenium tests against our whole product with IE6. Sometimes we hit crashes in the browser and I helped people debug them using windbg and find string locals on the stack so we could identify the bad code.
The idea that YT or any other Google product team would justify not CIing against IE6 or Firefox is absurd to me.
Can you elaborate? I kind of agree on the Kubernetes part in that it's really biased towards Google-scale, but I fail to see such biases in Go, despite having used it as my primary language for 4 years now.
The dependency management system and GOPATH. These seemed to all be designed for a monorepo. But transplanted to a distributed network of github repos - a terrible idea.
