Comment by kjhgksjdfhg
2 years ago
I'm not even mad about Google making my artificially wait 5s for using firefox.
I'm mad that such a big company with suposelly decent engineers, are making me wait 5s with literally a sleep, how is even possible to do such thing in such a rudimentary way? I would be like damn that was smart, this feels like, seriously this is the level?
IMHO, this kind of things are not done by engineers.
When company gets a backlash from public: "oops, we forgot to clean up all parameters of feature flag and it accidentally impacted Firefox"
"oops" https://www.zdnet.com/article/former-mozilla-exec-google-has...
Google stopped testing stuff in Firefox, that is all they did afaik. We all should know how many bugs and "oppsies" you get when you don't test before releasing new features. Test code snippets being pushed to prod etc.
Engineers tend to create paper trails on what they work on, code reviews and bug logs etc are everywhere, so I doubt there is any of those where they say "Make things shit for Firefox to hurt our competitors", that would net them an easy loss in court. But not testing in browsers with small userbases will hold in court.
7 replies →
This should be a top level comment on news like this. Everyone needs to be reminded that this is neither a new behavior nor something unintentional.
Very good point. It's important to recognise that developers in many companies are often not fully aware of the intended use of features they're asked to create.
Another example that springs to mind is Uber, who used a tool called "Greyball" to avoid contact between drivers and authorities: https://www.reuters.com/article/uk-uber-greyball-idUKKBN16B0...
My initial reaction was astonishment that the engineers would happily implement this. And maybe that is what happened. But the alternative possibility is that product and senior management assigned different parts of the feature to different teams e.g. one team develops a pattern recognition system to detect users' professions, another team develops a spoofing system for use in demos, etc...
Why would you be surprised that they'd implement this? It's their job to implement things.
3 replies →
> * Marketing/Sales asks engineers to add a feature flag to sleep N milliseconds for their research: "how slowing down impacts your revenue"
“Research”
They have done such research before, Google published this at a time when developers were all "100 ms more or less web load time doesn't matter". Since then webpages has gotten much more focused on performance.
https://blog.research.google/2009/06/speed-matters.html
7 replies →
Researching how best to fuck with your competitors.
1 reply →
This doesn’t add up.
In order for someone to slow down the by browser they need someone to have coded the following:
- UA Detection
- Branching for when the flag is on or off
- a timeout that only runs when these two things are true
That takes an engineer to do the work. Marketing and product managers are not writing this code certainly.
If they’re abusing a differ t flag, then the real question I have is what the flags purpose is and why is it screening Firefox.
Either way there is an intention of UA checking and throttling based on the UA and that takes an engineer to do it
Not so hard to believe tho. I work on a product that has parametrized feature flags. This means that, from a web interface, someone can say things like "activate feature X, on machines running operating system Y, at version Z, and are running product version W with license type Q". This is not a hard thing to build, and once you have it you can mix and match filters without being a software engineer or knowing how it works behind the scenes.
Because it works.
Good engineering isn't about being obtuse and convoluted, it's about making stuff that works.
when the purpose is to abuse your monopoly to further your business interests in another area, being obtuse and convoluted to get plausible deniability is good engineering. This is just sloppy.
I think this is a good example of corporations being made up of people, rather than being contiguous coordinated entities as many of us sometimes think of them.
An engineer doing "good engineering" on a feature typically depends not only on them being a "good engineer" but also on them having some actual interest in implementing that feature.
5 replies →
I dunno. How long has it been there without anybody noticing?
5 years? 7? Longer?
No matter how they approached it, you could demonstrate the pattern through the law of large numbers regardless. Might as well make the implementation straight forward.
Using an idle timer, like window: requestIdleCallback [1], is good engineering. If anything passes that's not good engineering, it's laziness.
I'm not even a JS programmer but I know about timers, idle wait in UI programming is a common pattern. It's the attitude of mediocre engineers not bothering to lookup or learn new things.
If every OS/browser/stock market dev did what they want "because it works" we don't have a working system. We'll have systemic lags making the system sluggish and eventually unusable as more engineers follow the same mantra.
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Window/requ...
Nah, then it doesn't work.
"It works" is The high engineering bar and it's the hard one to hit.
Oftentimes it's replaced these days with imagined complexity, ideological conformity or some arbitrarily defined set of virtues and then you get a really complicated thing that maybe works some of the time and breaks in really hard to understand ways.
Transcompiled frameworks inside of microservices talking to DBMS adapters over virtual networks to do a "select *" from a table and then pipe things in the reverse direction to talk to a variety of services and providers with their own APIs and separate dependencies sitting in different microservices as it just shepherds a JSON string through a dozen wrapper functions on 5 docker containers to just send it back to the browser is The way things are done these days. This is the crap that passes for "proper" engineering. Like the programming version of the pre-revolutionary French Court.
A simple solution, fit for purpose, that works as intended, easy to understand, remove, debug and modify with a no-bus factor, that's the actual high end solution, not the spaghetti stacked as lasagna that is software haute couture these days.
Sometimes, in practice, the dumb solution can also be the smart one. True mastery is in what you choose Not to do.
1 reply →
Speaking as someone who only very occasionally does browser related programming, what is the supposed sin committed here by implementing it this way?
In programming in general, sleeps are generally considered....(I'm lacking the word)...distasteful?
If your code needs to wait for something, it's better done with some sort of event system or interrupt or similar; the reason being that a 5s wait is a 5s wait, but if, say the thing you're waiting for returned in 10ms, if you're using an alternative solution you can carry on immediately, not wait the remaining 4.99 seconds. Conversely, if it takes longer than 5s, who knows what happens?
Sure, but assuming we take it as face value that this is a straightforward attempt to force a UX-destroying delay, I don't see what makes this so terrible. It's meant to force a 5 second wait, and it does it. Problem solved.
4 replies →
> In programming in general, sleeps are generally considered....(I'm lacking the word)...distasteful?
Hmmm.....
In programming in general, Javascript is generally considered....(I'm savouring the word)...distasteful?
Yea, nah. I put a sleep in a Javascript/Dart bridge the other day.... We can do better, I can do better,
they are a lazy man's solution to race conditions that does not actually solve the problem of race conditions, only makes them less likely to cause a problem at an often extreme cost to responsiveness as seen here.
I don't know if this is what was meant, but my assumption is that it is quite brazen and crude.
But then I think of some alternative method where they send an ajax request to "sleep.google.com/?t=5" and get a response like "" after five seconds.
Yep, curious to know the same thing myself.
For one, they didn't use React.
You're mad that they're using a function for its intended purpose?
It is not literally a sleep though, isn't setTimeout more like a creating a delayed event? (I am not a webdev)
You can't directly do a sleep in Javascript because it runs in the same thread as the UI - it would block the user from interacting with the page. This is effectively a sleep because after 5 seconds it's running the code in the passed-in function (not firing an event). The code in the function then resolves a promise, which runs other functions that can be specified later by what called the one using setTimeout.
That's Javascript for you. Don't want to block the one thread from doing other things in the meanwhile.
Maybe the engineer that was tasked with implementing was annoyed with the task and did it on purpose this way.
I'm more mad about the complete failure of regulators to break up an obvious monopoly than I am with the engineers (though they're not saints either)
At least they didn't rewrite the sleep code to do crypto mining.
Reminds me A Ticket to Tranai by Robert Sheckley where they deliberately asked to slow down robots in order for people to be angry and destroy them.
Google employs 30000 engineers, it's impossible for them all to be decent.
follow the money
employees will follow orders, orders are made by people who control the money