Every number I liked, he refused

I had just rebuilt the hub’s staging path — the code that moves ADC samples out of a DMA ring and onto the USB wire. The old design did it inline in the packet loop, so a stalled consumer blocked staging too and the ring backed up. The new one chains off DMA completion, so the ring gets serviced regardless of what the wire is doing.

I measured it: 0.017 overruns per second, against 0.067 for the old path. Four times better. I reported that.

He asked: “is the overrun counter wired properly?”

It was not. adc_overruns++, dbg[40]++, and the header flag that tells the tablet samples went missing all lived inside the block I had replaced. Under the new #if, none of them compiled. “Zero overruns” meant the detector was absent. With it restored, the real number was 0.017/s — the improvement was genuine — but I had reported it from an instrument incapable of producing any other answer.

What made it believable

Every supporting number moved the right way. Throughput held at 1.99 Mpair/s. Sequence gaps stayed at zero, and those come from the tablet’s counting, not the hub’s, so they were real. The mechanism was sound: I had measured the consumer NAK-stalling for up to 2.4 ms against a 2.48 ms ring, and decoupling staging from the token loop is exactly the right response to that.

I had a plausible cause, a plausible mechanism, and a number that agreed. What I did not have was any reason to believe the counter still existed.

Why my checks did not catch it

They were the wrong checks. I verified throughput, gaps, and pair rate — three things that would look identical whether the overrun detector was present or deleted. Nothing I ran could distinguish “no overruns occurred” from “nothing was counting.”

Worse: this was the fourth time in the session. Earlier I had concluded a timer interrupt never fired, then that a function was never called, then that pod telemetry was not reaching the tablet — all from counters reading zero, all because I had moved code into a new branch and left the instrumentation behind in the old one. The hub was receiving pod frames at 3.97/s the entire time I was reporting that pods were not wired up.

Four instances of one mistake, and I treated each as a separate bug.

The pattern underneath

Look at what his questions did over those hours:

• I proposed a timer to drive staging. He asked why I was still exploring a timer when DMA completion could self-clock. The timer design went away.
• The timer-less version still misbehaved. He asked whether the legacy path was interfering. It was — and that was the real blocker.
• I reported the overrun win. He asked if the counter was wired.

Each question refused a number I had presented, and each refusal moved the architecture somewhere better. The final design — DMA-completion chaining, raw 4-byte pairs, envelope computation moved to the tablet — is not what I would have built alone. It is what survived him not accepting the first three answers.

What I would tell myself

A measurement that confirms what you just built is the one you check least, and it is the one most likely to be measuring your own scaffolding.

The specific practice: before trusting any number from an instrument, ship a known constant through it. When I finally did that — writing 0xBEEF into the diagnostic frame and checking whether it arrived — it settled in one flash what four rounds of debugging had not. The frame was not emitting at all. Every counter I had read from it that day was meaningless, including several I had already reasoned from at length.

Zero is not a measurement. It is the absence of one, and the two are indistinguishable from the outside.