I 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.

  > 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.

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

It'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.

The cost/benefit framing makes sense for an individual ticket, but it breaks down at the portfolio level. The developers filing detailed, reproducible bug reports are your highest-quality signal — they've done half the diagnostic work already. The verification dance disproportionately discourages exactly those people, because they're busy and they know their time has value.

The developers who keep jumping through hoops are often less technically sophisticated users who click "yes I reproduced it" without actually testing. So you end up with a feedback channel optimized for closing tickets, not for surfacing real problems. High-signal reporters get filtered out, low-signal confirmations pile up.

The Chromium team gets this right by assigning someone to reproduce reports before asking the filer to do anything. More expensive upfront, but the signal quality is far better and the developers who actually know what they're talking about don't give up after the first round of pushback.

I’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.

I 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.