Speed-First, Serialize for a Reason

"Fast is the default, not the reward. Slow down only for a reason you can name."

The default is minimum wall-clock time

Dad's fleet-level preference is simple: get it done fast. So independent targets run fully in parallel by default. Nine machines that don't depend on each other update at the same time, not one after another. The presumption is concurrency; serialization is the thing you have to justify.

Serialize only for a real reason

There are exactly three reasons to run something in order rather than at once: a true dependency (target B genuinely needs target A finished first), an explicit preference (Dad says do it this way), or the control-plane host updating itself. Absent one of those, parallel is correct — and inventing a reason to serialize is just spending wall-clock time you didn't have to.

Safety without theater

Safety checks earn their place by doing real work: blocking invalid targets, detecting a shared failure before it repeats across the fleet. What they should not do is impose canary-then-wave-then-soak choreography on every campaign by reflex. Ceremony that doesn't reduce real risk isn't safety — it's latency in a safety costume. Match the caution to the actual danger, the same way risk classes match ceremony to blast radius.

The office-last exception

The one principled serialization worth naming: a control-plane host can't safely reboot itself out from under the very campaign it's running, so it updates after its peers. That's not a ritual — it's a genuine dependency, because the campaign needs its own control plane to survive long enough to finish. Every other serialization should point at a dependency just as concrete, or it doesn't belong.

Parallel by default; serialize only for a named dependency. Caution you can't justify is just latency — and a campaign that's slow for no reason is a campaign you'll be tempted to skip.

Code

Parallel by default; serialize only for a reason·python

independent, dependent = partition(targets)

# Default: run every independent target at once -- minimum wall-clock time.
run_in_parallel(independent)

# Serialize ONLY for one of three real reasons:
#   1. a true dependency (B needs A finished first)
#   2. an explicit Dad preference
#   3. the control-plane host updating ITSELF -> it goes last, because it
#      cannot reboot itself out from under the campaign it is running.
run_after(dependent, waits_for=independent)
run_last(control_plane_host)   # office-last: a dependency, not a ritual

# Safety checks block invalid targets and detect a SHARED failure.
# They do not impose canary/wave/soak on a campaign that doesn't need it.

Exercise

Take a batch task you run serially out of habit (deploying to servers, updating machines, processing files). Ask, for each pair: does B actually depend on A finishing, or are they independent? Rewrite the plan to run the independent ones in parallel, and list every serialization you kept — each with the concrete dependency that justifies it.

Hint

If your only reason for going one-at-a-time is 'it feels safer,' that's the tell. Real dependencies survive the question 'what breaks if these run at the same time?'; imagined ones don't. Keep the ones that survive; parallelize the rest.

Speed-First, Serialize for a Reason

The default is minimum wall-clock time

Serialize only for a real reason

Safety without theater

The office-last exception

Code

External links

Exercise

Progress

Comments 0