3 ms·

It's pretty much industry standard for all consumer products to deliver metrics back to home base. Honestly there are many good reasons to do so and it does res

It's pretty much industry standard for all consumer products to deliver metrics back to home base. Honestly there are many good reasons to do so and it does result in finding real problems and solving them. While I understand the argument that we did fine in these products for decades without them, the complexity of the products was also a lot less back then. Finding issues via metrics from the production fleet is an incredible tool and anyone who's deployed software to a server probably understands this. I'd rather focus on standardizing a transparent and privacy safe way to gather these metrics. Consumers would know what metrics are collected and there would be guarantees that privacy is kept. There are ways to accomplish this today. Providing a way to disable metrics is never going to be sufficient for anyone other than a power user.

0points 2y ago
> Honestly there are many good reasons to do so and it does result in finding real problems and solving them. Honest question, what is a good reason to do this? My Logitech software sends telemetry to Logitech. My VW apparantly sends my GPS coordinates. How is this useful for improving their hardware?
- surajrmal 2y ago
  I'm not sure I can defend all choices various vendors make, but there are plenty of signals that are helpful. Precise gps coordinates seem unnecessary, but some sort of region based information can help correlate whether there is a particular problem that might happen at far higher rates in hilly terrain or specific humidity levels. Users also often use products in a way that doesn't line up with how the product owner thinke it should be used. Metrics don't replace interviewing people but it might help you craft the right questions. In the case of a Logitech mouse, it might be useful to understand if people are actually using those extra features you've added or maybe it's worth removing in a future version. The most obvious metric that everyone wants to know is failure or crash rates. After a software update it's always good to know if those rates went up. Those errors may be recoverable, but it's good to try and understand them to improve reliability. Maybe pairing android auto with specific phone models is more problematic, or maybe trying to pair Bluetooth is particularly bad under specific conditions like high thermals in warmer climates. It's pretty difficult to interop testing with all possible parties in all conditions.
  - hulitu 2y ago
    > some sort of region based information can help correlate whether there is a particular problem that might happen at far higher rates in hilly terrain or specific humidity levels. You know what will help in those situations ? Testing. It is expensive, i know. Why not skip it and just analyse the KPIs from the telemetry. /s
    - surajrmal 2y ago
      Testing is not really an economically viable option in all cases. Ecosystems are simply to diverse and products are so complex that covering every case is not really possible. There is likely no software you use today short of projects like sqlite which don't leverage user reported bugs or telemetry to improve the software.
effdee 2y ago
> I'd rather focus on standardizing a transparent and privacy safe way to gather these metrics. Consumers would know what metrics are collected and there would be guarantees that privacy is kept. I'd rather see laws to have it disabled by default. People who don't mind can then opt-in again.
- surajrmal 2y ago
  If we do that the relative cost of software will increase and reliability will overall decrease. This doesn't sound like a great outcome for end users who will end up dealing with both of these things.
carra 2y ago
Defending this because "it's industry standard" is no better than justifying any wrong practice because "it's always been done this way".
- surajrmal 2y ago
  My point is that it's done this way for a reason beyond the nefarious ones that people in hn always seem to assume. Engineers want this data because it helps them do their job, bit because some product person wants to use it to sell it or use it to train an ML model. There is certainly extraneous data collected because the incremental cost of doing so once you've established the pipeline is small and eventually someone does make a bad decision, but that's where we should focus our energy. Otherwise you're just making a lot of folks jobs harder because their software runs doesn't run in the cloud. An unintended consequence of this might be to push even more software into the cloud which would otherwise run on client side.
hulitu 2y ago
> Honestly there are many good reasons to do so and it does result in finding real problems and solving them. Tell that to Microsoft. Although their products have telemetry, they become shittier every day.

0points 2y ago

> Honestly there are many good reasons to do so and it does result in finding real problems and solving them. Honest question, what is a good reason to do this? My Logitech software sends telemetry to Logitech. My VW apparantly sends my GPS coordinates. How is this useful for improving their hardware?

surajrmal 2y ago
I'm not sure I can defend all choices various vendors make, but there are plenty of signals that are helpful. Precise gps coordinates seem unnecessary, but some sort of region based information can help correlate whether there is a particular problem that might happen at far higher rates in hilly terrain or specific humidity levels. Users also often use products in a way that doesn't line up with how the product owner thinke it should be used. Metrics don't replace interviewing people but it might help you craft the right questions. In the case of a Logitech mouse, it might be useful to understand if people are actually using those extra features you've added or maybe it's worth removing in a future version. The most obvious metric that everyone wants to know is failure or crash rates. After a software update it's always good to know if those rates went up. Those errors may be recoverable, but it's good to try and understand them to improve reliability. Maybe pairing android auto with specific phone models is more problematic, or maybe trying to pair Bluetooth is particularly bad under specific conditions like high thermals in warmer climates. It's pretty difficult to interop testing with all possible parties in all conditions.
- hulitu 2y ago
  > some sort of region based information can help correlate whether there is a particular problem that might happen at far higher rates in hilly terrain or specific humidity levels. You know what will help in those situations ? Testing. It is expensive, i know. Why not skip it and just analyse the KPIs from the telemetry. /s
  - surajrmal 2y ago
    Testing is not really an economically viable option in all cases. Ecosystems are simply to diverse and products are so complex that covering every case is not really possible. There is likely no software you use today short of projects like sqlite which don't leverage user reported bugs or telemetry to improve the software.

effdee 2y ago

> I'd rather focus on standardizing a transparent and privacy safe way to gather these metrics. Consumers would know what metrics are collected and there would be guarantees that privacy is kept. I'd rather see laws to have it disabled by default. People who don't mind can then opt-in again.

surajrmal 2y ago
If we do that the relative cost of software will increase and reliability will overall decrease. This doesn't sound like a great outcome for end users who will end up dealing with both of these things.

carra 2y ago

Defending this because "it's industry standard" is no better than justifying any wrong practice because "it's always been done this way".

surajrmal 2y ago
My point is that it's done this way for a reason beyond the nefarious ones that people in hn always seem to assume. Engineers want this data because it helps them do their job, bit because some product person wants to use it to sell it or use it to train an ML model. There is certainly extraneous data collected because the incremental cost of doing so once you've established the pipeline is small and eventually someone does make a bad decision, but that's where we should focus our energy. Otherwise you're just making a lot of folks jobs harder because their software runs doesn't run in the cloud. An unintended consequence of this might be to push even more software into the cloud which would otherwise run on client side.

hulitu 2y ago

> Honestly there are many good reasons to do so and it does result in finding real problems and solving them. Tell that to Microsoft. Although their products have telemetry, they become shittier every day.