[KronisLV]

> I'm curious why corporate development teams always feel the need to spy on their users?

Cause the alternative is viewing all of your app as one opaque blob - you don't know exactly how it's being used, which features actually need your attention, especially if you're spread thin. If you're in consulting or something like that and the clients haven't let you configure and/or access analytics (and the same goes for APM and log shipping), it's like flying blind. Couple that with vague bug reports instead of automated session recording and if you need to maintain that, you'll have gray hairs appearing by the age of 30.

Take that disregard of measurement and spread it all across the development culture and you'll get errors in the logs that nobody is seeing and no insights into application performance - with the system working okay at a load X, but falling over at X+1 and you having to spend late evenings trying to refactor it, knowing that it needs to be shipped in less than a week because of client deadlines. Unless the data is something that's heavily regulated and more trouble than it's worth, more data will be better than less data, if you do something meaningful with it.

> Would Git have been significantly better if it had collected telemetry, or would the data not have just been a distraction?

Knowing the most common fuck ups and foot guns might inform better CLI design. Otherwise people saying that it's good have about as much right to do so as saying that it's bad (at least in regards to UX), without knowing the ground level truth about what 90% of the users experience.

[skydhash]

> you don't know exactly how it's being used, which features actually need your attention, especially if you're spread thin.

Why not conduct a survey?

> vague bug reports instead of automated session recording and if you need to maintain that, you'll have gray hairs appearing by the age of 30.

If it's a customer, why not reach directly to him?

> with the system working okay at a load X, but falling over at X+1 and you having to spend late evenings trying to refactor it,

No one is talking about telemetry on your servers. We're talking about telemetry on client's computers.

[KronisLV]

> Why not conduct a survey?

Large amounts of time before getting feedback, low percentage of people responding, not an accurate sample of all users (you will get signal from the loudest ones) and inaccurate data (biases in perception) instead of measurable reality. Not useless, but not a full replacement for telemetry.

> If it's a customer, why not reach directly to him?

Layers of indirection (and also the slowness of getting through them). You might not control the processes and approvals needed to do that in a non-startup environment. You will probably control enough of the app to add various technical solutions to aid you in collecting information.

> No one is talking about telemetry on your servers.

I am. Culture of not collecting client side data also often comes together with a culture of not collecting server side data properly either. Competent teams will evaluate both. My argument is that all of this data can meaningfully help in development and that other approaches don't replace it well enough.

[skydhash]

> Large amounts of time before getting feedback […]inaccurate data (biases in perception) instead of measurable reality.

I think perception is more valuable because that is the only way of measuring frustration with the UX of the software. Something may be used a lot, but is painful to everyone.

> You might not control the processes and approvals needed to do that in a non-startup environment

In such environment, it’s often true that features are governed by third parties as well. You collect telemetry, but have no say in what user will get and experience.

> Culture of not collecting client side data also often comes together with a culture of not collecting server side data properly either

I strongly doubt that. We have way more tools for collecting data on servers than on doing telemetry.

——

As a user, I essentially want my software to stay the same as long as possible. If I really need a new feature or am struggling with a bug, that’s when I contact the developers. If the developers are dogfooding their own software, new feature can be quite a delight especially when their profile is similar to yours.

But telemetry driven development is how you get features no one asked for.

[KronisLV]

Very reasonable arguments!

> As a user, I essentially want my software to stay the same as long as possible. If I really need a new feature or am struggling with a bug, that’s when I contact the developers.

I largely agree and think that if the world had more users like you, it would be a better place, with more stable software. Unfortunately, in any industry with competing solutions, your users probably won't go through all that trouble and will just pick another product, alongside companies having all sorts of incentives to ship stuff (sometimes the deadlines being made up) and therefore needing to make informed decisions about what to build and what to maintain ASAP. I think we'll get features nobody asked for, telemetry or no telemetry. As for everything else, it depends.