The Wrong Question is a universal phenomenon of software debugging in which the first question asked about a bug is invariably the wrong question, the wrong question generates elaborate and technically impressive theories that are all incorrect, and the right question — which is always simpler, always more fundamental, and always slightly embarrassing in retrospect — is asked last.
The phenomenon was formally documented during the April 2026 Notification Buffer Incident, when an AI generated five sophisticated theories about why an SSE channel was overflowing before a developer asked the question that should have been asked first: “How many events are we actually sending?”
The answer was 114. The buffer held 100. The mystery was arithmetic.
“None of that convinced me.”
— riclib, four words that collapsed five theories into one question, The Hundred-Event Buffer, or The Night the Server Screamed into the Void
The Pattern
The Wrong Question follows a reliable sequence:
Phase 1: The Symptom. Something is broken. A buffer overflows. A page is slow. A test fails intermittently. The symptom is observable and unambiguous.
Phase 2: The Wrong Question. The developer asks a question that assumes a sophisticated cause. “Why is the consumer not draining fast enough?” “Is there a race condition in the reconnection logic?” “Could the OS be throttling background tabs?” These questions are interesting. They suggest complex failure modes. They make the debugger feel intelligent.
Phase 3: The Investigation. The developer follows the wrong question into increasingly elaborate territory. TCP buffer sizes are calculated. Connection lifecycle diagrams are drawn. A theory about stale session references requires understanding three layers of goroutine management. Each theory is internally consistent. Each theory is wrong.
Phase 4: The Intervention. Someone — usually a senior developer, often in pajamas — says something devastating in its simplicity. “How many events are we sending?” “What does the log actually say?” “Have you counted?”
Phase 5: The Right Question. The right question is asked. The right question is always boring. The right question is always about quantity, not mechanism. “How many” instead of “why.” “What is” instead of “what could be.” The right question can be answered with a calculator.
Phase 6: The Silence. The specific silence of realizing that the answer was arithmetic all along.
“The wrong question is always asked first. The right question is always obvious after someone says ’none of that convinced me.’”
— Observed pattern, The Hundred-Event Buffer, or The Night the Server Screamed into the Void
Why the Wrong Question Is Asked First
The Wrong Question is asked first because the right question is boring and the wrong question is flattering.
“Why is the consumer slow?” implies a system complex enough to have consumer-side bottlenecks, TCP-level interactions, and subtle concurrency bugs. It implies that the debugger is operating at a level of sophistication commensurate with the system’s complexity.
“How many events are we sending?” implies that someone didn’t count. It implies that the bug is not subtle. It implies that the system is not sophisticated — it is merely wrong, in the simplest possible way, and nobody noticed because everybody assumed the wrongness would be interesting.
The Wrong Question persists because developers would rather debug a fascinating race condition than admit they didn’t do the multiplication.
The Four Words
The most effective diagnostic tool in software engineering is not a debugger, a profiler, or a distributed tracing system. It is a senior developer who listens to your theory and says: “None of that convinced me.”
These four words perform the following operations:
- They do not tell you what’s wrong
- They do not tell you what’s right
- They tell you that your current direction is not producing conviction
- They force you to ask a different question
The different question is always the right question. Not because the senior developer knows the answer, but because the wrong question has been eliminated, and what remains — however boring, however simple, however arithmetical — is the truth.
Measured Characteristics
Theories generated before counting: 5
TCP timeout: wrong
Stale sessions: wrong
Background tab throttling: wrong
EventSource reconnection race: wrong
"Could be cosmic rays": not formally proposed
but the trajectory was clear
Correct theory: arithmetic
(114 > 100)
Time spent on wrong questions: ~20 minutes
Time spent on right question: ~30 seconds
Sophistication of wrong questions: impressive
Sophistication of right question: embarrassing
Words required to redirect: 4
("none of that convinced me")
Calculator required: yes
(but not used until minute 21)
The Corollary
The Wrong Question has a corollary: The Right Question Was Available All Along.
The data to answer “how many events are we sending?” was in the code from the start. Line 336 of runnable.go. The progress callbacks. The three-event broadcast per callback. The multiplication was trivial. The information was not hidden. It was merely not sought, because seeking it would have required asking a boring question, and the boring question does not make the debugger feel intelligent.
“The right question doesn’t make you feel smart. That’s how you know it’s the right question.”
— The Lizard, who has never once asked the wrong question first, because lizards do not have egos, only patience
See Also
- Debugging the Void — What happens when the wrong question leads to debugging code that isn’t the problem
- Theatre Testing — Tests that ask the wrong question: “does the mock work?” instead of “does the system work?”
- The Town Crier Pattern — The system that was discovered by finally asking the right question
- The Hundred-Event Buffer, or The Night the Server Screamed into the Void — The incident that documented the pattern
