9 ms·

Going to give a guess as to more pragmatic reason this came about: they don't have a requirement or test for it. Some engineer was asked to make a feature. Tha

• arpa 5y ago
  We're jaded enough to assume the reverse of Hanlon's razor (for me it was when google dropped their "don't be evil", hard).
  • andreareina 5y ago
    At a certain point (size of org, number of incidents) you decide that mere stupidity is not an adequate explanation. It doesn't have to rise to the level of actual malice, but willful negligence is on the table.
• PragmaticPulp 5y ago
  I agree. We ran into this issue all of the time at a past employer with a lot of tech enthusiasts in the customer base: We’d make harmless changes to our own code that broke someone’s community software that relied on undocumented APIs from time to time. Without fail, someone from the community would jump to conclusions and start stirring up controversy with claims that we were deliberately breaking 3rd-party applications. The strange thing was that people from all over the internet wanted to get in on the controversy and anger, even when they didn’t use the software that broke. This created a weird incentive for software authors to complain loud and wide about any breaking changes because it became free advertising for their software. We tried quietly helping some of them fix their software with hints, but that quickly became an avenue for “<company> caves to pressure from angry customers” stories that only made our problem worse.
  • ssivark 5y ago
    Fascinating. I’m curious what were the landscape of MOs you/company evaluated. Eg: would it have been possible to encourage a slightly more organized relationship with the enthusiasts by communicating the challenges to them?
    • PragmaticPulp 5y ago
      It’s tough. I engaged with the community a lot at first and we made efforts to give them what they wanted. Over time this created a weird, unhealthy dynamic where parts of the community felt entitled to special treatment from the company. Some of them felt like they were stakeholders in the company and that we were obligated to incorporate them into the development process. At worst, it reminded me of some of the “parasocial” relationships described in social media situations, where the followers start to feel like they were owed much more than regular customers due to their dedication as super customers. Even worse, some of them had their own YouTube channels, newsletters, or Discord communities for our products and would often threaten to turn them against us if we didn’t do what they wanted. That part was especially saddening.
      • ssivark 5y ago
        Hmmm, that’s interesting in an unfortunate way that can only be learned from experience. I have wondered about why companies don’t better engage with enthusiasts / power users, and now I have a better appreciation for the challenges. Thanks for sharing.
  • semi-extrinsic 5y ago
    https://xkcd.com/1172/ https://xkcd.com/1172/
    • vertis 5y ago
      We could save everyone a lot of time commenting on HN just by auto categorizing by XKCD.
  • 5y ago
• spaceribs 5y ago
  I actually tend to agree with this take honestly. If I was an Architect over at netflix implementing QoE, and all my minions were making calls directly to the html element for seeking instead of using the API I created, I'd want to catch that regression quickly too. That said, there is no public API for that functionality beyond the DOM element for anyone else, so I'm not sure what was expected for any sort of integration.
• DaiPlusPlus 5y ago
  > they don't have a requirement or test for it. Automated and thorough testing of client-side JavaScript is a huge, huge burden because you cannot simply run a script in isolation in a headless V8 instance or something: you need the entire browser and clone environment running. Secondarily: the major tools for performing automated testing of web-applications within modern browsers are all lacking in some critical way, for example while Cypress automates Chrome fine, for some reason it loads the entire SUT into an <iframe>!!!! That alone will introduce massive differences from production, top-level browsing (the project is full of hacks that do things like re-write `window.top` so that the SUT can almost believe it's not running in an iframe, but enough differences leak through). For all the effort Google put into Angular's Protractor, Chrome does not make this easy.
  • jefftk 5y ago
    I've been pretty happy with the WebDriver protocol: https://developer.mozilla.org/en-US/docs/Web/WebDriver https://developer.mozilla.org/en-US/docs/Web/WebDriver Works across browsers and lets you simulate the user and check anything you want.
    • muro 5y ago
      Sure, it's technically possible, just very unstable.
  • margaretdouglas 5y ago
    The issue isn't that the testing is challenging. The ask here is Netflix covers all third-party Chrome plugins that manipulate the playback experience. Is it really Netflix's job to ensure all changes are compatible with third party tools like the one linked here, or others like Language Reactor?
    • davidzweig 5y ago
      If they wanted to, it wouldn't be much work for them to provide a stable API for such tools. Mostly it would involve making certain functions/properties that are internal to their modules/closures available on a global object. For Language Reactor, it would be helpful to have a handful of stable classes or ids on different HTML elements, and an email when major changes are incoming. Even just to have access to the new code early on in the rollout would be nice. There is a frantic two weeks every year where LR is breaking for users and we can't debug, because we don't have the new code yet.
• nindalf 5y ago
  Comment sections are no fun if we’re going to assume good intent of people we don’t know. I suggest we ignore this reasonable explanation and start a frenzied campaign against this obviously malicious change.
  • margaretdouglas 5y ago
    I feel like I'd find this comment more humorous if it wasn't a parody of what is actually happening.
• tyingq 5y ago
  I think that's true for many things Netflix does, but wrapping the seeking event handler for HTMLMediaElement with private state specifically to catch unexpected seek events seems like it would be known to break 3rd parties. That's fine, of course, they aren't claiming to support a public api. But it doesn't seem accidental or some oversight.
  • surajrmal 5y ago
    Any change to frontend behavior will likely break someone at Netflix's scale. They are likely desensitized to breaking these things, otherwise they would never make any changes.
    • tyingq 5y ago
      That's roughly what I was saying. It wasn't an oversight or accident.
• TeMPOraL 5y ago
  > It probably wasn't intentional, just incidental. The reason people assume intent is because such things often enough are intentional. Making your product harder to interoperate with outside of your control is a well-established practice for SaaS companies, particularly the big ones[0]. The reason this blog post has a story is not because this behavior is surprising, but because it's annoying, and because it can be construed as an accessibility issue - accessibility being the only excuse for having sane computing experience that won't be dismissed as "silly power users with their silly wishes". -- [0] - See e.g. the lengths to which Facebook goes to make it hard to work with its DOM.
  • Secretmapper 5y ago
    To be fair, Facebook has very deep incentives to do this (ie. to prevent adblocking) I'm not sure what such incentive is here for Netflix
    • RNCTX 5y ago
      Facebook has no problem lying to advertisers about how much their money buys, I'd say it's much more likely that Facebook is concerned with preventing scraping.
• whoknowswhat11 5y ago
  It's honestly better in some cases just to lock these types of folks out - you can save yourself a ton of a headaches later. Look for words like offended, nightmare, deeply upset, outraged - if you see a lot of that - disengage!
• panic 5y ago
  The thing is, organizations have their own sort of "intent" apart from the people involved in them, and the process you describe is exactly how that intent is expressed. Who decides what should be tested and how? Who can be affected without anyone noticing or fixing the problem? Which problems are deemed important to fix and which are more of a "nice to have"? It's possible for most people in an organization to care about something -- in the sense that they'll tell you they care if you ask them, and if you point out a problem they'll spend some time trying to fix it -- while the organization itself doesn't actually care in the slightest. The people who care can't fix the problems if they don't see them in the first place or if other problems have already been prioritized above them.