The bug that doesn't exist: Gorgias and the error nobody can reproduce

A user reports that the form didn’t send anything. There’s no error in the dashboard, no trace, no new row in the database. It gets tested in three browsers and works all three times. The ticket is closed with the sentence that closes half the tickets in the world: can’t reproduce.

Two weeks later it happens again. And again there’s nothing to look at.

The man who proved that nothing exists

Gorgias of Leontini, sophist and contemporary of Socrates, wrote the treatise with the most provocative title in antiquity: On Non-Being. He defended three chained claims:

1. Nothing exists.
2. If anything existed, we couldn’t know it.
3. If we could know it, we couldn’t communicate it to anyone.

It’s usually read as a guild joke: proof that with enough technique you can argue anything at all. But it works better as a diagnosis than as a joke, because it describes exactly the three walls an intermittent bug runs into. A real bug hits them in order, and at each one somebody is willing to close it.

First claim: it doesn’t exist

“Can’t reproduce” doesn’t mean “doesn’t happen”. It’s a statement about the observer, not about the system: it describes what the person writing it failed to see.

The asymmetry of proof is uncomfortable. Whoever fails to reproduce it has refuted nothing; they failed to reproduce it, which is a different thing. Whoever suffered it holds the only evidence available, even without a stack trace: it happened to them.

Intermittents live where the development environment doesn’t reach. A session expiring halfway through a form. Latency that only shows up with real data. Two tabs open. A phone in battery-saver mode that freezes the timer. A race condition that needs two people clicking a second apart, which never happens when the person testing is alone.

Reproducing is a luxury. Once you have it, the bug is half fixed; the hard part is everything before that.

Second claim: it exists, but can’t be known

Here the system stops being an accomplice and becomes mute. You can’t know what you didn’t instrument: the application only knows what you asked it to remember, and that agreement was signed months before the bug showed up.

A log line saying error saving isn’t knowledge. It’s formatted noise. Knowledge would be which input arrived, which user, which client version, at what time and through which branch of the code. Without an identifier tying together the events of a single request, what’s left isn’t a story: it’s three stories chopped up and shuffled, and anyone can read into them whatever they already suspected.

Adding traces is never the expensive part. The expensive part is discovering, mid-incident, which ones you needed.

The rule: if a bug doesn’t reproduce, the first job isn’t to fix it. It’s to make it visible. A blind patch cures nothing, and it changes the scene: you lose the only lead you had, and you’ll never know whether it stopped appearing because you touched it or because today wasn’t its day.

Third claim: it’s known, but can’t be communicated

The third wall is language, and it’s the one that burns the most time.

“It doesn’t work.” “It gets stuck.” “Sometimes it won’t let me.” The user isn’t being vague: they’re describing an experience, and an experience isn’t a technical fact. Their sentence is honest and useless at the same time, the way “it hurts here” is true and isn’t a diagnosis.

The bridge is three questions, none of them technical: what did you expect to happen, what happened instead, and when and on what did you do it. A bug form asking for that turns noise into working material. One asking for “description of the error” collects “it doesn’t work” all over again.

And it’s worth looking the other way too, because there we’re the sophist: closing a ticket with “fixed” communicates nothing either. It doesn’t say what was broken, who it happened to, or how to check that it isn’t happening now.

Gorgias as hygiene, not as defeat

The sophist wasn’t after truth: he was after winning the argument. Which makes him a good model of what a system in production does. It won’t lie to you with a big red error; it will answer confidently, fast, in a perfectly convincing tone, and sometimes the answer will be false.

The only thing that works against that is the burden of proof. Whoever claims it’s fixed, proves it. And “fixed” has an exact meaning: there’s a specific case that used to fail, that case no longer fails, and you know why it failed. Without the third part there’s no fix, there’s a coincidence with good PR.

In epistemology for developers the argument was that a test doesn’t prove the code works, only that it hasn’t failed yet. An intermittent is exactly that gap, but occupied: someone is living inside the margin of error.

Before closing one of these

Three things, in order:

• Write it as a checkable sentence. Not “sending sometimes fails”, but “with an expired session, the send returns 200 and saves nothing”. A sentence like that can be attacked; the other one can only be archived.
• Instrument before touching. If it doesn’t reproduce, the urgent thing is to see it, not to cure it.
• Don’t close it out of silence. A bug that stops appearing isn’t fixed: it’s waiting. Usually until Friday afternoon.

Gorgias wrote his treatise to prove that language never quite touches reality. In production the opposite happens, and it’s worse: it touches it constantly. “It doesn’t work”, “can’t reproduce”, “it’s fixed now” — each of those three sentences decides whether anyone keeps looking. And the bug, meanwhile, is still there, under no obligation to exist while you watch.