4 ms·

"Never attribute to stupidity that which can be adequately explained by malice" -Hacker News

by andrewmutz 7y ago

ineedasername 7y ago
How about: "Sufficient levels of stupidity are indistinguishable from malice"
- Supermancho 7y ago
  Indifference is not stupidity. "My feature is done. I don't care if or how it hurts the user."
  - justinclift 7y ago
    Possible a bad example, as that one sounds incredibly stupid. ;)
  - ineedasername 7y ago
    I think indifference is a perfectly good substitute here as well: "Sufficient levels of indifference are indistinguishable from malice". Yep, that works too.
diffeomorphism 7y ago
"Google is a small indie company. Don't be so hard on them." -- Some guy on HN
simias 7y ago
This is a systematic issue with many of Google's services. They have the money and manpower to test their interface on Firefox. We're talking about a modern, generally standard-compliant browser here, not IE6. Getting those websites to perform decently on Firefox shouldn't be a problem for Google. I can believe that they don't purposefully break Firefox for the sake of it, but it's clear that they make no effort to make their websites compatible and they don't appear to consider these issues like bugs. If it works on Chrome then it's good enough. I suspect that internally compatibility issues with Firefox are not even considered bugs at all, it's just the way it is and it's up to Mozilla to fix their browsers to be compatible with Chromium (I have no insider knowledge, but it's the way it feels from the outside).
- thu2111 7y ago
  It's an artifact of how they develop and test software. And ultimately Firefox suffered these bugs because their product wasn't compelling. Googlers push new code to production regularly, with the cycles getting faster all the time. It used to be biweekly (as the article alludes). Then it was weekly. Then it was daily. Then it was "push on every green build". If you push to production literally the moment your test suite passes, then your browser compatibility is a function of two things: 1. What the engineers developing a feature use. 2. What is easiest to build automatic test suites with. In both cases the answer was Chrome and Chrome. Firefox has never had good support for API driven embedding. Embedded Gecko never took off. The automated GUI test drivers that became popular were mostly WebKit/Chrome based, with some support for IE and using it via RDP to a VM. Nobody forces Googlers to use any particular browser but Chrome was the best so that's what they used. Also, Google culturally is always on the bleeding/cutting edge of HTML stuff. So it's more likely to hit edge cases than others. Result: occasional glitches where Firefox bugs or Google app bugs intersected. They always got fixed quickly when reported. Only crazy people would think this was some conspiracy involving tens of thousands of developers who mysteriously never leaked their evil plan. Mozilla would have done themselves a world of benefit if they'd been pushing hard their own CI/integrated Gecko based test suite and made it the best.
  - bzbarsky 7y ago
    > They always got fixed quickly when reported. Having been involved in a number of these reports, this is flat-out false. Basic "fix your CSS to not rely on this Chrome bug; here's the exact diff you want to make it work both in browsers that follow the CSS spec and in Chrome" things regularly take 2-3 months to apply on the Google side. Basic "your browser user-agent sniffing is broken _again_ in the same way as three months ago" things take a month or two to fix. Disclosure: Mozilla employee, have been cced on far too many of these bug report threads over the years.
    - thu2111 7y ago
      The article where the Mozilla guy complained said two weeks, but, yes. Months is possible. Maybe we have a different definition of quickly. Disclosure: former Google employee, I did many pushes and fixed browser compatibility bugs whilst I was there. In the timeframe we're talking about most products were on a biweekly push cycle. In the ideal case where there was no delay at all between you reporting a bug and it reaching the right person inside the company who could fix it, if that day happened to be on a branch cut day then that's a minimum of a two week delay to reach production unless the bug was so severe that the entire product was hosed for all Firefox users. Minor glitches in rarely used screens wouldn't count for a rollback or emergency push, for instance. But sometimes pushes fail. There's a severe bug, attempts to fix it are too slow and the push window closes so the servers are rolled back. Now the latency is a month. That's only software bugs. Now include the time taken for the bug report to be triaged, mis-directed, pinged, rerouted to the right person. Now include delays incurred if that person goes on holiday, gets sick or has other higher priority tasks, as bug handoff works about as well there as anyone else. That can easily add more time. Finally, regressions are to be expected in an environment where the extent of browser testing is a function of engineer interest rather than centrally mandated. If they weren't testing Firefox well enough before they weren't testing it well enough after either. If Google had a central rule about which browsers had to be supported then I didn't know about it. There was just an assumption you'd try to support the browsers people used as best you could. I'm not saying it was awesome or right, just that this sort of thing was not Firefox specific and there were plenty of IE or Safari compatibility bugs too.
_jal 7y ago
I remember when it was Microsoft's browser that everyone feared. They, too, had a remarkable run of incompetence that only ever seemed to flow one way.
- username90 7y ago
  The problem with IE was that Microsoft intentionally coupled IE versions with Windows versions so you had a lot of ancient versions in use. So you had to ensure that all web apps you wrote were compatible with IE6-IE10 at the same time which was a huge pain. That wont happen with chrome since it is not coupled to any OS, people can just update whenever they want for free getting all the latest features. Microsoft being pressured to stop that practice is a boon to the entire industry.
  - _jal 7y ago
    > The problem with IE was that Microsoft intentionally coupled IE versions with Windows versions I was there. That was the headline cause of their legal troubles, but far from the only thing Microsoft got up to. They intentionally broke other sites, threw misleading messages and tried to play games with standards. In other words, many actions that look familiar today with different actors.
thoughtleader31 7y ago
"If a company I like has plausible deniability, then their intentions are definitely innocent" -Hacker News
r00fus 7y ago
Gray's law applies: "sufficiently advanced stupidity is indistinguishable from malice"

"Never attribute to stupidity that which can be adequately explained by malice" -Hacker News

ineedasername 7y ago

How about: "Sufficient levels of stupidity are indistinguishable from malice"

Supermancho 7y ago
Indifference is not stupidity. "My feature is done. I don't care if or how it hurts the user."
- justinclift 7y ago
  Possible a bad example, as that one sounds incredibly stupid. ;)
- ineedasername 7y ago
  I think indifference is a perfectly good substitute here as well: "Sufficient levels of indifference are indistinguishable from malice". Yep, that works too.

diffeomorphism 7y ago

"Google is a small indie company. Don't be so hard on them." -- Some guy on HN

simias 7y ago

This is a systematic issue with many of Google's services. They have the money and manpower to test their interface on Firefox. We're talking about a modern, generally standard-compliant browser here, not IE6. Getting those websites to perform decently on Firefox shouldn't be a problem for Google. I can believe that they don't purposefully break Firefox for the sake of it, but it's clear that they make no effort to make their websites compatible and they don't appear to consider these issues like bugs. If it works on Chrome then it's good enough. I suspect that internally compatibility issues with Firefox are not even considered bugs at all, it's just the way it is and it's up to Mozilla to fix their browsers to be compatible with Chromium (I have no insider knowledge, but it's the way it feels from the outside).

thu2111 7y ago
It's an artifact of how they develop and test software. And ultimately Firefox suffered these bugs because their product wasn't compelling. Googlers push new code to production regularly, with the cycles getting faster all the time. It used to be biweekly (as the article alludes). Then it was weekly. Then it was daily. Then it was "push on every green build". If you push to production literally the moment your test suite passes, then your browser compatibility is a function of two things: 1. What the engineers developing a feature use. 2. What is easiest to build automatic test suites with. In both cases the answer was Chrome and Chrome. Firefox has never had good support for API driven embedding. Embedded Gecko never took off. The automated GUI test drivers that became popular were mostly WebKit/Chrome based, with some support for IE and using it via RDP to a VM. Nobody forces Googlers to use any particular browser but Chrome was the best so that's what they used. Also, Google culturally is always on the bleeding/cutting edge of HTML stuff. So it's more likely to hit edge cases than others. Result: occasional glitches where Firefox bugs or Google app bugs intersected. They always got fixed quickly when reported. Only crazy people would think this was some conspiracy involving tens of thousands of developers who mysteriously never leaked their evil plan. Mozilla would have done themselves a world of benefit if they'd been pushing hard their own CI/integrated Gecko based test suite and made it the best.
- bzbarsky 7y ago
  > They always got fixed quickly when reported. Having been involved in a number of these reports, this is flat-out false. Basic "fix your CSS to not rely on this Chrome bug; here's the exact diff you want to make it work both in browsers that follow the CSS spec and in Chrome" things regularly take 2-3 months to apply on the Google side. Basic "your browser user-agent sniffing is broken _again_ in the same way as three months ago" things take a month or two to fix. Disclosure: Mozilla employee, have been cced on far too many of these bug report threads over the years.
  - thu2111 7y ago
    The article where the Mozilla guy complained said two weeks, but, yes. Months is possible. Maybe we have a different definition of quickly. Disclosure: former Google employee, I did many pushes and fixed browser compatibility bugs whilst I was there. In the timeframe we're talking about most products were on a biweekly push cycle. In the ideal case where there was no delay at all between you reporting a bug and it reaching the right person inside the company who could fix it, if that day happened to be on a branch cut day then that's a minimum of a two week delay to reach production unless the bug was so severe that the entire product was hosed for all Firefox users. Minor glitches in rarely used screens wouldn't count for a rollback or emergency push, for instance. But sometimes pushes fail. There's a severe bug, attempts to fix it are too slow and the push window closes so the servers are rolled back. Now the latency is a month. That's only software bugs. Now include the time taken for the bug report to be triaged, mis-directed, pinged, rerouted to the right person. Now include delays incurred if that person goes on holiday, gets sick or has other higher priority tasks, as bug handoff works about as well there as anyone else. That can easily add more time. Finally, regressions are to be expected in an environment where the extent of browser testing is a function of engineer interest rather than centrally mandated. If they weren't testing Firefox well enough before they weren't testing it well enough after either. If Google had a central rule about which browsers had to be supported then I didn't know about it. There was just an assumption you'd try to support the browsers people used as best you could. I'm not saying it was awesome or right, just that this sort of thing was not Firefox specific and there were plenty of IE or Safari compatibility bugs too.

_jal 7y ago

I remember when it was Microsoft's browser that everyone feared. They, too, had a remarkable run of incompetence that only ever seemed to flow one way.

username90 7y ago
The problem with IE was that Microsoft intentionally coupled IE versions with Windows versions so you had a lot of ancient versions in use. So you had to ensure that all web apps you wrote were compatible with IE6-IE10 at the same time which was a huge pain. That wont happen with chrome since it is not coupled to any OS, people can just update whenever they want for free getting all the latest features. Microsoft being pressured to stop that practice is a boon to the entire industry.
- _jal 7y ago
  > The problem with IE was that Microsoft intentionally coupled IE versions with Windows versions I was there. That was the headline cause of their legal troubles, but far from the only thing Microsoft got up to. They intentionally broke other sites, threw misleading messages and tried to play games with standards. In other words, many actions that look familiar today with different actors.

thoughtleader31 7y ago

"If a company I like has plausible deniability, then their intentions are definitely innocent" -Hacker News

r00fus 7y ago

Gray's law applies: "sufficiently advanced stupidity is indistinguishable from malice"