SAID: Train for the Production You Actually Run

I once spent months adding weight to my pull-ups, convinced it would hand me a muscle-up. My weighted pull-up went up nicely. My muscle-up didn’t move. The transition — that awkward moment where you rotate over the rings — needed its own practice, and no amount of heavy pulling taught it.

That’s SAID: Specific Adaptation to Imposed Demands. The body adapts to the exact stress you give it. Strength transfers, but less than you’d hope; skill transfers least of all. If you want to get good at a movement, practise that movement, under conditions close to the real thing. (The training side is covered in more depth in SAID Principle.)

Systems adapt to their tests

Software doesn’t adapt biologically, but teams and codebases do adapt to what they’re tested against. A suite that only exercises happy paths produces a codebase that’s excellent at happy paths. A staging environment with ten users and perfect latency produces confidence about ten users and perfect latency.

Then production turns up with a different sport: flaky mobile networks, real data shapes, a feed that bursts to hundreds of messages a second, a third-party API that times out every Tuesday.

Where suites quietly train the wrong thing

• Mocks that are too polite. Every request succeeds instantly with tidy data. Real APIs return partial pages, nulls in places the type says they can’t, and 503s.
• Fast, local, empty. Tests run against an empty database on a fast laptop. Production has years of data and a slow phone.
• Time-frozen. No test covers the session that expires mid-flow, the token that refreshes while a request is in flight, or the clock change.
• Load-free real-time UIs. A live dashboard tested with one message a second will behave very differently at three hundred.

Cheap ways to add specificity

You don’t need a full production clone, in the same way you don’t need competition conditions every session. You need enough of the specific demand.

• Failure fixtures at the network boundary. With MSW (Mock Service Worker) the same handlers can serve slow, failing and malformed responses to unit tests, Storybook and local development. Make the unhappy states first-class scenarios, not afterthoughts.
• Throttle by default. Run e2e tests and local dev sessions under realistic network and CPU throttling now and then. Playwright and browser devtools make this one line.
• A synthetic feed for real-time UIs. Replay recorded or generated bursts at production rates and watch frame times, not just correctness.
• Production-shaped data. Anonymised or generated datasets with the awkward edges real data has: long names, empty lists, unicode, huge numbers.
• Game days. Deliberately break a dependency in a safe environment and practise the response. That’s the closest thing to a competition rehearsal.

Where the metaphor breaks

In training, more specificity is nearly always better close to the event. In software, perfect specificity means testing in production, which you can do (feature flags, canaries, observability) but with care. The goal is “specific enough to catch the failures that matter”, balanced against cost and speed of feedback.

And bodies have one production environment. Systems often have several — browsers, devices, regions — so you have to choose which demands to impose. Let incidents and analytics tell you where the real load is.

Takeaways

• Ask what your tests actually train the system for, and compare it with what production demands.
• Make failure, slowness and messy data part of everyday testing, not a special project.
• Add specificity cheaply at the boundaries: network mocks, throttling, synthetic feeds, realistic data.
• Rehearse incidents like you’d rehearse a competition: before you need to.

Related: Golden Paths and the Recommended Routine (bake realistic defaults into the template) and Regress, Don’t Grind: Graceful Degradation (what to do when the demand exceeds capacity).