"It doesn't work": eight things that sentence can mean

"It doesn't work" is the most frequently filed bug report in software and it carries almost no information. Not because the reporter was careless, but because from where they are standing, all failures look the same: they wanted an outcome and did not get it.

From where the developer is standing, that sentence covers at least eight different defects with different owners, different urgencies and different fixes.

The eight

1. It threw an error. The best case, because the software knew it had failed and said so. The error text is usually the whole diagnosis, and it is usually the thing the reporter did not paste.

2. Nothing happened. The click registered nowhere. No error, no change, no feedback. Usually a swallowed exception or a failed request nobody surfaced, and it is worse than an error because the software does not know it is broken.

3. It hung. A spinner that never resolves. Distinct from "nothing happened" because something did start, and the interesting question is what it is waiting for.

4. It did something, but the wrong thing. The dangerous one. The operation reported success and produced a result that is incorrect. Nobody notices for weeks, and by then the wrong data has been acted on.

5. It worked, partially. Half the rows, some of the files, most of the records. Almost always a limit or a timeout somewhere, and almost always silent, which puts it close to category four in terms of damage.

6. It was too slow to be usable. The feature functions. Nobody can wait for it. Reporters classify this as broken and they are right to, but it will be triaged as performance and lose to a crash.

7. It worked, but they could not find it. Not a defect at all. A discoverability problem, filed as a bug because the outcome was identical from the outside.

8. It did exactly what it was designed to do, and the design is wrong. The disagreement about intent. This one belongs to whoever owns the product decision, and it will sit in an engineering queue for a month before anyone works that out.

Why the reporter cannot tell you which one

It is tempting to conclude that reporters should be more specific. But look at the list from outside the system: several of these are indistinguishable without access to logs, and at least two are indistinguishable without knowing what the software was supposed to do.

Someone who exports 4,300 rows and receives 1,000 has no way to know whether that is category four, five or eight. They know the file is wrong. The classification requires knowledge they do not have and cannot get.

So the burden of classification cannot sit with them. It has to sit with whoever asks the next question.

The question that splits the list fastest

If you only get to ask one thing, ask this:

What did you see on screen at the moment it failed?

Not what went wrong. What they saw. An error message separates category one. "Nothing at all" separates two. "It was still loading when I gave up" separates three. "It looked fine" pushes you towards four, five or eight, which is exactly the group where the next question matters most, because those are the failures that do not announce themselves.

Compare that with the question most people actually ask, which is "can you send reproduction steps". That is the right question for categories one, two and three, and completely wasted on the rest.

Two follow-ups worth having ready

Once you know it "looked fine", two questions carry most of the remaining load.

"What did you expect to see instead?" Separates category eight from everything else, and it does so gently. If the answer describes behaviour the software was never designed to have, you have found a product conversation, not a bug.

"Was any of it right?" Separates four from five. Wholly wrong output and partially wrong output have almost nothing in common as defects, and reporters rarely volunteer the distinction because from their side both are "the file is wrong".

The point of a taxonomy

Not to make reporters use it. They will not, and it would not help if they did.

The point is that whoever reads the incoming issue should know that "it doesn't work" is a question rather than a statement, and should know which eight answers are possible. That turns triage from an act of interpretation into an act of elimination, which is a much easier thing to do quickly, and a much easier thing to hand off.