On unfamiliar hardware, tooling isn't overhead

Two projects, roughly twenty years apart, taught me the same lesson from opposite directions.

At Intel, working on Fax-over-IP, the hard part was never really implementing V.17 and V.34 — it was that fax protocol failures don't announce themselves. A handshake that's slightly off doesn't crash; it just occasionally fails in a way that looks like random flakiness unless you have a way to actually observe the protocol state at the moment it goes wrong. So before pushing on modem density, the real leverage was in building diagnostic and validation tooling that could turn "sometimes this doesn't work" into "this specific step, this specific way, this often."

At Redline, building the Point-to-Multipoint wireless system, the constraint was more literal: the processor was custom, so there was no assembler and no debugger for it. Nothing existed to build against. The first real engineering decision on that project wasn't about packet classification or memory management — it was to spend the time building the low-level tooling first, knowing it wouldn't demo as a feature to anyone.

Both cases share a shape: the visible, fundable work (fax protocol support, a wireless base station) depends entirely on invisible, unglamorous infrastructure (diagnostic tooling, a toolchain) that doesn't show up in what the system does — only in whether you can trust that it does it correctly, or fix it when it doesn't.

The temptation, especially under time pressure, is to skip straight to the visible work. On unfamiliar or constrained hardware, that's usually a false economy. Every hour not spent building the tools to observe a system honestly gets paid back later, with interest, in the form of debugging sessions with no visibility into what's actually happening.