You Only Get to Compile Five Times
Treat every hardware build as one of a handful of irreversible compiles a year.
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 3
- Confidence
- 92%
Software engineers compile and debug hourly; hardware engineers get roughly four or five 'compiles' — full builds — ever, and the last one is mass production with no over-the-air fixes. This forces a more conservative development posture: front-load reliability testing, and explicitly design for the statistical variance of every part. It's the core mental model that explains why hardware discipline differs from software.
Origin
Caitlin Kalinowski, framing hardware development for software audiences.
Core principles
- 01A released mass-production design is final — you can't ship updates to atoms
- 02Because compiles are scarce, reliability checks must happen in-line with the program, not after
- 03Parts arrive across a ±3-sigma distribution; the worst-case pairing must still assemble and work
- 04The goal is a high-yield, low-return build on the final compile
How to run it
- 1
Count your compiles and treat them as scarce
Recognize you will do only ~4-5 full builds before mass production, each costing 3-5 months. Plan the program around that scarcity rather than assuming cheap iteration.
Watch out Assuming you can 'fix it in the next build' burns one of your very few remaining compiles.
- 2
Move reliability testing in-line, and be conservative
Do the reliability checks and tests during the program, not at the end, and default to more conservative design choices — because once you compile the final time, the parts are in the world and can't be changed.
- 3
Design for part variance, not the nominal part
Every part comes off a distribution. For any two mating parts, assume you'll get the smallest of one and the largest of the other and still have to assemble them across millions of units. Solve for that last half-percent so the final build yields high and returns stay low.
Pro tip Graph the tolerance distribution of assembled parts and design so the plus/minus three-sigma extremes still fit and function together.
Watch out People systematically underestimate part variance; ignoring it produces low yield and high returns at scale.
In the wild
Late in the Quest 1 program (at EVT, when engineering should be done), the computer-vision lead and the hardware team had interpreted a positional tolerance spec differently (a per-pair ±0.15mm vs a global one). The mismatch meant the headset couldn't lock onto the user's position in space, forcing an architectural change: locking the bottom two cameras to a steel bracket as a source of truth while letting the other two float.
→ The team adapted, held the schedule, and shipped on time — and the favored-pair design was actually better — but it was a stressful scramble they wished they'd caught four months earlier.
Common mistakes
Carrying a spec ambiguity into a late build
Two teams reading the same tolerance spec differently surfaced only at EVT, when a redesign is most costly; unresolved spec interpretation is a hardware-specific landmine.
Designing to nominal instead of to the distribution
Ignoring that parts vary across ±3 sigma means worst-case pairings fail to assemble or perform, tanking yield once you're producing at volume.
Is it for you?
Best for
Software leaders and PMs building intuition for why hardware timelines and caution differ from their world
Not ideal for
Rapid-prototyping or one-off/low-volume builds where mass-production yield economics don't apply
From the transcript
“In hardware, we only get to compile our code quote unquote like four or five times.”
“we have to be more conservative and we have to take our time”
“the part variance is pretty high.”
From the episode
Why we’re at the beginning of the AI hardware boom
Caitlin Kalinowski (ex–OpenAI, Meta, Apple)