Comment by reaperducer

> I don't understand why Google and some other tech companies use their users as involuntary, unpaid guinea pigs. No consent. No opt-out.

It's crazy to me to think about when I was in college (in the mid aughts), I was doing a lot of research into Native American cultures. The amount of releases, paperwork, and other hoops you had to jump through in order to just interview subjects was pretty daunting.

The fact we have become involuntary research subjects without any protections as a research subject or easy way to opt out of these companies data collection (which itself is an ongoing form of research) is staggering to thing about.

I still do'nt understand how people ask these questions when it's been it since 30 years.

Isn't that what most A/B testing is?

Bias up front: I work at Google but am not speaking for Google.

> involuntary, unpaid guinea pigs.

I don't see how this is involuntary. You are choosing to use the product. If you choose to use the product, yes, you may be exposed to features that the product has. If you don't want to be exposed to those features, the way to opt out is to not use the product.

> What's the motivation?

It lets the company incrementally roll out and test features in real-world network configurations at scale. As far as I know, almost all tech companies do this.

Let's say you're Fapplebooglezon and you have an idea to put kitten emojis on the "Buy Now" button. Before you ship that, you want to make sure that:

1. The feature works correctly. It doesn't crash or have significant performance problems.

2. Users, in aggregate, like the change. No one wants to ship a "New Coke" debacle. It's bad for the company (they lose money) and bad for users (they don't like the product).

3. Your servers and network can handle the consequences of that change. Maybe users will be so excited that they all click "Buy Now" twice as much. You need to make sure your servers don't crumble under the increased load.

These are reasonable things that benefit both the company and users. So the way features and changes are usually shipped is like:

1. The feature is implemented behind some kind of flag. [0]

2. "Fishfooding" [1]: The team developing the feature starts using it. This gives you some feedback on "does the feature work correctly" but that's about it. The team owns the feature, so they are biased in terms of its usability. And they are on a privileged network and not a large enough population to verify how this affects the distributed system.

3. "Dogfooding": The entire company starts using it. This starts to give you some usability feedback because now people who don't have a stake in the feature are being exposed to it. But it's still skewed since employees are likely not a representative user population.

4. "Canary": The feature is enabled for a randomly selected small population of external users. Now you start getting feedback on how the feature performs in the wild on real-world machines and networks. The percent of users is kept small enough to not crush the servers in case anything goes awry, but you can start getting some performance data too.

5. "A/B testing": Now you start collecting data to see how behavior of users with the feature compares to users without it. You can actually start to get data on whether the feature is good or not.

6. Assuming everything looks OK, you start incrementally rolling it out to a larger and larger fraction of users. All the while, you watch the servers to make sure the load is within expected bounds.

7. Once you get to 100% of users and things look good, you remove the flag and the feature is now permanently enabled.

> Is it simple laziness because they don't want to deal with wetware?

Google, like most other companies, also does lots of user testing and user surveys too. But that doesn't give you insight into the technical side of the question — how the feature impacts the behavior of your distributed system.

You may not be aware of this, but this kind of in-the-wild product testing is something almost all businesses do, all the time. Food companies test new products in grocery stores in selected cities [2]. Car manufacturers drive camoflaged prototypes on the road [3]. Restaurant chains tinker with recipes to see how sales are affected. There is absolutely no guarantee that the Coke you're drinking today has the same ingredients as the one you had yesterday.

You seem to think this is some nefarious scheme, but it's just basic marketing. You want to make a thing people like, so you make two things and measure which one people like more. People "opt in" and "consent" by using the product. If you don't want to be a "guinea pig" when McDonald's changes their French fry recipe, don't buy the fries. If you don't want to test out new Chrome features, don't use Chrome.

[0]: https://martinfowler.com/articles/feature-toggles.html

[1]: https://www.reddit.com/r/google/comments/3qpdnn/anyone_knows...

[2]: https://smallbusiness.com/product-development/best-u-s-citie...

[3]: https://www.cnbc.com/2017/01/20/camouflage-the-incognito-way...

1. It's about the money.

2. See 1.

... what?

If you aren't paying for it; you are the product. Simple.

Do you get the consent to observe everyone you interact with?

It's because most people don't care and if it means that they have a better product at the end of it, they'll take the trade.

Google employees are not a random sample of their user base, so such experiments would be meaningless.

See the fiasco where they broke Terminal Services last year as an example of what can go wrong even when doing experiments on the whole user base.

Also consider how to measure the usage of web features Google's own websites don't use, but are popular on e.g. intranets in Korea.

A/B testing isn't bad, it's a good thing. People are notoriously not very good at giving feedback. Experiments and usage statistics let you get the ground truth about what they really value, and what's really working.

Microsoft Vista was a Windows 7 beta, and was "necessary" to basically experiment on the entire Home market, to make the product stable enough for enterprise.

Although Window 7 may have been one of the most complex software deployments in history, needing to support decades of poorly written drivers, while making the system both stable and compatible.

> No consent. No opt-out.

Do you understand what licensing is? That's one of the underlying aspects that's important with software and why you can't treat it like other things you buy. I'd add it's also why things that adopt software-style licencing models are bad too.

A company creates a licence with terms and you agree to use the licence under those terms by using the software. The terms are difficult to change unless you have leverage. The only party other than the company is often the regulatory authority. Regulation is limited in the US at best when compared to the EU. If you are from the EU then you probably assume the US works similarly, but most Americans don't recognize issues like this one. When they do, it's hard to fight the incumbents and make something opt-in, or ban it outright.

> What's the motivation? Is it simple laziness because they don't want to deal with wetware? (the start of your first paragraph applies here too)

It's fairly simple. The motivation is making correct decisions based on the gold standards of decision-making that some people aspire to. The model is not dissimilar to clinical trials where a treatment is given to some individuals and not to others. The hope is that this form of experimentation removes bias and let's the product manager make the best decisions.

Based on this thinking it is not possible to test with just Google's employees. For many decisions, the bias will be significant, and ultimately the belief is that worse decisions will be made for users.

I'm trying to convey that in as neutral way as possible. I think this can be a useful technique, but I think that there is little discipline and accountability in the wider software world compared to medicine. You have PMs who'll routinely just run an A/B test longer to collect more data (that's better, right?), but invalidate their results, just to please management.

If anyone is going to implement this approach then I'd trust Google to implement it effectively to meet their needs. They do it on a large scale across their products and have many layers of people to ensure it's effectively meeting their needs. As stated in the previous paragraph, this doesn't mean that other people do it right, or that everyone in Google does it right every time. I'm sure they've had a fair share of failed experiments.