[pjc50]

Reminded of a post I saw the other day referencing Clausewitz to say "if your ideal military strategy is politically unachievable, it's not the ideal strategy". If going for opt-out telemetry makes your customers hate you and you're forced to retreat under a hail of fire, going opt-in is not a mistake.

There's also a philosophical problem in going too deep into "customers don't know what they want" and A/B testing everything to death: you end up using it as a substitute for dialogue. Ultimately customers are making conscious decisions. You have to make the case rather than assert that it's "better" from behind your metrics dashboard.

[lozenge]

Yes, the author of the article makes the mistake of... not listening to or responding to what the other side thinks, just because she disagrees with them. No concern was addressed in her article.

[twilysparkle]

For what it's worth I have actually listened to the arguments that the other side had made, but I didn't want to focus on that in place of the stuff that I felt was missed.

[lozenge]

I think the Go developers argued for it very well, but there is a reason they decided to go with opt-out, so calling it a mistake makes no sense to me unless you address that reason.

[twilysparkle]

My argument in TFA is that going opt-in biases the data so much that it makes the process of building that system a mistake. Of course, under the assumption that it is ethically correct to build such a system in the first place.

[Uvix]

In that scenario, not going opt-out is not a mistake. But going opt-in probably is a mistake, because the data will be useless, so it’s a waste of time to implement.

[PaulKeeble]

For those conscious of the security implications of that code even existing it all comes down to whether you trust Google, I would argue at this point you definitely shouldn't. Given that if you program in Go now and have code you really wouldn't just give Google then you probably need to run all your go executions in a VM without network access. This alone is going to be ardious enough from a security point of view to make other languages more interesting.

The entire idea is bad, the defaulting reduces the impact to many but the very existence of this telemetry is enough to take more significant security defence against the tool. Once you start doing that as an organisation Go becomes legacy with a strong desire to replace it. Its definitely a mistake to make it opt in, the data will be lower quality and it will still drive security concerns.

[majorhelmet]

> all comes down to whether you trust Google

Not true. The code is open source and everyone can trivially with minimal effort check that they are sending only the data they said they would send.

[hgsgm]

Why would data be useless?

[Jailbird]

I'd say there are times when bad data is worse than no data. Consider that the farther away you get from it, the parties involved are either unaware or unwilling to treat it as bad data, so they make make harmful decisions.

[tjoff]

And opt-out or even mandatory data is without doubt quite bad to start with. And the interpretation of the data is rarely flawless or even pretends to be objective.

So if someone says that opt-in data is useless, I'd say that out-out data is just as useless.

And then we have to pretend that implementation, collection and analysis and then further actions would make it worthwhile.

[michaelt]

Googler 1: Do we need this telemetry opt-out functionality? How many users are using it?

Googler 2: The data says 100% of users are opted in, so deprecating the obsolete and unpopular opt-out functionality is the evidence-based choice. Ignore the shrill demagogues on the mailing list saying otherwise, their anecdotes are meaningless.

[mplanchard]

Ah, are you also a Bret Devereux reader?

[pjc50]

Correct! acoup.blog articles are always highly upvoted here, too.

[mplanchard]

I love his writing. Had just read the piece on Ukraine that you were referencing the day before, so I recognized the Clausewitz (drink!) quote :)