[beembeem]

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.

[nradov]

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.

[SchemaLoad]

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

[PunchyHamster]

If bug contains instructions for reproduction most of that will be eliminated.

[account42]

99.99% of bug reports do not

You're lucky if there is an accurate description of what produced the bug on the customers' specific setup at the time of reporting.

[PunchyHamster]

well then closing it with inactivity is fine.

[pixl97]

Quite often reproduction information will only reproduce the bug in the customers environment, hence there is a lot of incomplete state on what is actually causing the problem.

It's pretty terrible in enterprise because there is so much 3rd party crap touching things it shouldn't that love to cause fun problems.

[alexdowad]

There's obviously some nuance here, but the fact is that much modern software is riddled with bugs, and this is sub-optimal for everyone (both software users and software builders). Most of the bugs which frustrate and irritate software users are not due to uncontrollable events such as cosmic rays flipping a bit. Most of them are plain old code defects.

But, you do have a valid point. Allow me to rephrase it this way: The answer is not for software companies to spend unbounded amounts of engineer time chasing every reported bug.

But there are ways that we, as an industry, can do better, and it's not by pouring all our time into chasing hard-to-diagnose bugs. Here are a few ways that I personally see:

1. Some very powerful technologies for finding many bugs with little engineering effort already exist, but are not widely used. As an example, coverage-guided fuzzing is amazingly good at finding all kinds of obscure bugs. The idea of coverage-guided fuzzing was known from the 1990's, but it took AFL (in ~2013) to take it mainstream. Even now, much of the industry is not benefiting from the awesome power of coverage-guided fuzzing. And there are other, equally powerful techniques which have been known for a long time, but are even less accessible to most software developers.

So: spread the word about such techniques, and for programming language/platform developers, work on making them more easily applicable. This could help many software companies to catch a great number of bugs before they ever go to production.

2. Similarly, there are extant historical computing systems which had very powerful debugging facilities, much better than what is currently available to most developers. The ideas on how to make our platforms more debuggable are already out there; it's now a matter of popularizing those ideas and making them readily accessible and applicable.

3. Since it's widely known that many bugs (real bugs, not "cosmic rays") are extremely hard to reproduce, an admirable target for us to aim for as developers is to implement debug logging in a way which allows us to root-cause most obscure bugs just by examining the logs (i.e. no need to search for a reproducer). Some real-world systems have achieved that goal, with very good results.

4. While there is currently much buzz about using LLM-based coding agents to write code, I think an almost better use case for coding agents is in triaging bug reports, diagnosing the bugs, finding reproducers, etc.

I've recently had a couple of shocking experiences where, just given a written description of an intermittent, hard-to-diagnose bug, a coding agent was able to search an entire codebase, identify the exact cause, and write a reproducer test case. (And this after multiple experienced human programmers had looked at the issue but failed to identify the cause.)

In summary, I think there are ways to "cut the Gordian knot" of bug reports.

[ImPostingOnHN]

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

[ikiris]

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

Truenas literally takes this approach to bugs.

[annie511266728]

Right. The problem isn’t closing the ticket, it’s pretending more work is happening than actually is.

“Needs verification” is fine if someone has actually tried to reproduce it. Otherwise it’s just a nicer way of saying “we’re not going to look at this.”

[account42]

Most 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]

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

[hu3]

I'll steal this to my projects bug template! /s

"Please consider cosmic rays hitting the computer, defective ram chips, weird modifications of the system before submitting the bug. Unlesss you explicitly acknowledge that, your bug will be closed automatically in 30 days. Thank you very much"

[godelski]

  > For every customer who takes the trouble to submit a formal bug report there are likely many others who just live with it

This reminds me of a fairly old but famous story about ignoring bugs from Linux users. I couldn't find the HN post but here's slashdot

  | Though only 5.8% of his game's buyers were playing on Linux, they generated over 38% of the bug reports. Not because the Linux platform was buggier, either. Only 3 of the roughly 400 bug reports submitted by Linux users were platform specific

The short is that they initially ignored it, triaging, but it was a mistake. Especially since the culture of Linux users is to submit more detailed bug reports. That their submissions help general users.

Don't just a bug report by its cover, judge it by its merits. We're all biased to dismiss them and find an excuse to ignore them. But that just leads to bad software.

https://m.slashdot.org/story/391921

[galangalalgol]

Yeah competition works. I don't like nexus that much but they accept every ticket I've opened and fix it the next release. Two things I think affect that. One, my ticket has the name of a fortune 100 next to it. Two, artifactory will eat them alive if they don't keep customers happy.

[beembeem]

Yes and no.

Funny you mention Microsoft because I used to see bug reports for Windows. I can tell you there was a ton of low quality "SOMEONE HACKED MY COMPUTER" or similar feedback (and sometimes just unintelligible ranting) that was completely inactionable or unreproducible. I otherwise do agree with your premise that large monopolistic businesses can sit on large swaths of feedback without worrying about competition - and that this is a problem.

However, for most software projects and businesses, the lack of repeated feedback is a signal that the issue isn't important.

As a user I would hope that the software author/publisher is prioritizing important problems. Closing one ticket is not indicative of organizational rot, as you say.

[godelski]

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

Exactly. Thank you for saying this.

[falcor84]

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.

[conductr]

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.

[FridgeSeal]

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

[nijave]

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.

[account42]

And total 24/7 surveillance also makes police work easier, but it's still wrong.

[nijave]

...you're claiming error tracking and monitoring are wrong?

We're talking about companies you voluntarily have a relationship with, not the government

[account42]

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