3 ms·
Yep. On the other side of the curtain this often isn't nefarious. It's a simple cost/benefit analysis of spending time on something that one user is complaining
by beembeem 6mo ago
Yep. On the other side of the curtain this often isn't nefarious. It's a simple cost/benefit analysis of spending time on something that one user is complaining about versus a backlog of higher business priorities. I've seen this in my work and it makes me sad for the user, but it often does take a bit of effort to spear these bug reports through.
- falcor84 6mo agoIt's a false dichotomy - something being "a simple cost/benefit analysis" doesn't remove the ethical dimension, and can absolutely be nefarious. A movie villain saying "it was just business" doesn't make their actions less villainous.
- conductr 6mo agoI’d argue that there should be no higher business priority than shipping a product you already sold. If you sold a product and your customer spends their time documenting exactly why and how you sold them something that’s broken, you should make that a high priority. As a natural progression, you’ll start shipping less buggy / better tested products and that’s how you unlock yourself from the obligation you made to your existing customers to do other work. Not directed at you of course, just the proverbial “you” from the frustration of a purchaser of software.
- FridgeSeal 6mo agoCareful saying that too loudly, the “ship new features at all costs” gang will come for your head. They don’t approve of things like “quality software” and “making stuff that works past the demo and cursory inspection” or “actual user utility”.
- nradov 6mo agoI totally understand that from the perspective of individual employees: they have little incentive to do more than the bare minimum to close tickets. But this behavior is typically a symptom of broken corporate culture and failure to align internal metrics. For every customer who takes the trouble to submit a formal bug report there are likely many others who just live with it, and badmouth you to other customers. Doing deep investigations of even minor bug reports also tends to expose other, more serious latent bugs. And root cause analysis allows you to create closed-loop solutions to prevent similar future bugs. Large monopolistic tech companies like Apple and Microsoft can afford to ignore this stuff for years because there are few realistic alternatives. But longer term eventually a disruptive competitor comes along who takes product quality and customer service more seriously.
- SchemaLoad 6mo agoThere's also going to be mountains of bugs resulting from cosmic rays hitting the computer, defective ram chips, weird modifications of the system the reporter hasn't mentioned. You could sink an infinite amount of time investigating and find nothing. At some point you have to cut off the time investment when only one person has reported it and no devs have been able to reproduce it.
- ImPostingOnHN 6mo agoWhat if no devs even tried to reproduce it, and they have no reason to believe they've fixed the bug with any other changes? That seems to be the case described in the article. In such a situation, I think it's dishonest to ask the reporter to expend even more effort when you've spent zero. Just close it if you don't want to do it, you don't have to be a jerk to your customers, too, by sending them off on a wild goose chase. Otherwise, why not ask the reporter to reproduce the issue every single day until you choose to fix it in some unknown point in the future, and if they miss a day, it gets closed? That seems just as arbitrary.
- account42 6mo agoMost of the time there is some reason to believe that the bug could be fixed though, i.e. there were non-trivial code changes around that area.
- ImPostingOnHN 6mo agoMost of the time, there isn't any reason to believe it could be fixed, i.e. there were not any non-trivial changes around that area. What you're describing happens less frequently, and in such cases, the devs should discuss that with the reporter. In this specific example, it looks like Apple gave no indications that such changes had happened, and no indications they had even spent a nonzero amount of effort following the reproduction instructions with either the old code or the new code.
- ikiris 6mo ago
- godelski 6mo ago> this often isn't nefarious. It's a simple cost/benefit analysis of spending time on something that one user is complaining about versus a backlog of higher business priorities. You can triage without closing tickets. So it is nefarious. It is metric hacking If you're having trouble reproducing, tag "needs verification" or something else. But closing a ticket isn't triaging, it is sweeping problems under the rug
- olvy0 6mo agoExactly. Thank you for saying this.
- nijave 6mo agoI can sort of back that for desktop apps but telemetry is so trivial for webapps needing a reproducer is almost an embarrassing admission the operator has no clue what they're doing. Error tracking and tracing make it fairly straight forward to retroactively troubleshoot unreproducible issues.
- account42 6mo agoAnd total 24/7 surveillance also makes police work easier, but it's still wrong.
- nijave 6mo ago...you're claiming error tracking and monitoring are wrong? We're talking about companies you voluntarily have a relationship with, not the government
- account42 6mo agoThe telemetry is almost always not voluntary and neither is the relation ship with the companies in the first place unless you mean that technically you could become a hermit living in the woods.
- AbanoubRodolf 6mo ago[flagged]