The control knob over the granularity of grouping in a flow: one cost (fixed setup amortised per item) falls as the group grows while another family (delay, inventory, risk concentration, feedback lag) rises — producing a convex total-cost curve with an interior optimum.
Batch size is how many things you scoop up and handle as one group. Carry the groceries in big armfuls and you make fewer trips, but if you drop one armful you lose a lot at once, and you wait longer before anything gets put away. Carry a little at a time and you make more trips, but you find out fast if something's wrong. There's a 'just right' amount in the middle.
The Just-Right Group
Batch size is the number of items you group together before processing them — like how many cookies you put on one tray. There's a tug-of-war: bigger groups share the setup cost so each item is cheaper, but bigger groups also mean each item waits longer, you find out about mistakes later, and if one batch goes bad you lose more at once. Smaller groups cost a bit more per item but give you fast feedback and spread out the risk. Because one cost goes down and the others go up as the group grows, there's a best size somewhere in the middle. And if you're still learning how to do the job better, small batches help most, because the lessons come back to you quickly.
The Grouping Knob
Batch size is the pattern where a stream of work is processed in grouped quanta of size N — not one at a time, not all at once — exposing a trade-off curve. As N grows, the fixed setup cost amortised per item shrinks, but a family of opposing costs grows: delay to feedback, latency for any individual item, risk concentrated in one batch, inventory held while the batch accumulates, and coupling between items that share fate. Strip the vocabulary and it's a control knob over the granularity of grouping in a flow, with one cost falling per item and another rising, giving an optimum that depends on how big the fixed cost is, how cheap delay and inventory are, and how fast you must learn. The clean canonical case is the economic order quantity, whose portable form says optimal batch size scales as the square root of setup cost over flow cost. Two distinctions give it depth: coupling-of-fate makes big batches a risk-concentration device, not just a cost-saving one; and feedback-lag means small batches accelerate the learning signal, so they can win over long horizons even when they lose on a single snapshot.
Batch size is the structural pattern in which a stream of work, information, material, or attention is processed in grouped quanta of size N rather than one item at a time or all at once, exposing a trade-off curve between the fixed setup cost amortised per item — which shrinks as N grows — and a family of opposing costs that grow with N: delay to feedback, latency for any individual item, risk concentration within a single batch, inventory held while a batch accumulates, and coupling between items that share fate. The defining commitments are a stream of arrivals of nominally independent items, a per-batch fixed cost that does not scale with N (setup, transition, transaction, review, release ceremony), a per-item flow cost that grows with N (waiting, inventory, feedback lag), a coupling consequence whereby items in the same batch share fate, a total-cost curve in N with an interior minimum, and a feedback-lag consequence whereby large batches delay the learning signal that would improve the upstream operation. Strip the substrate vocabulary and what remains is a control knob over the granularity of grouping in a flow, with one cost falling per item as the group grows and another rising, producing an optimum that depends on how large the fixed cost is, how cheap inventory and delay are, and how fast the system must learn — the canonical clean instantiation being the economic order quantity, whose substrate-independent form (optimum scales as the square root of the ratio of setup cost to flow cost) is itself portable. Two distinctions give the pattern depth: the coupling-of-fate consequence makes large batches a risk-concentration device, not merely a cost-amortisation device; and the feedback-lag dimension means that when the operation itself is being improved, small batches accelerate the learning signal and compound over time, so they can dominate at long horizons even where they lose on any single trade-off snapshot.
It separates the setup cost from the per-item processing cost, the delay cost from the risk cost and the feedback-lag cost — and distinguishes attacking the setup cost (shifting the whole curve) from merely riding the curve to its minimum.
It compresses every "how often" and "how much at once" decision into a small parameter set — fixed cost, flow cost, arrival rate, coupling cost, learning half-life — solved by one constant trade-off shape.
It enables the convexity argument (small perturbations of N are cheap), the dominance-of-feedback argument (the optimum shifts smaller when the operation is being learned), the setup-cost-attack argument, and coupling-of-fate reasoning.
Inventory to software: EOQ and release cadence share the setup-versus-holding trade-off — the structural basis of the DevOps movement.
Manufacturing to meetings and code review: SMED's setup-reduction insight ports to preparation rituals and small PRs.
Loan portfolios to software releases: Vintage-year coupling is the same coupling-of-fate that makes large releases risky, yielding to the same split-the-batch fix.
The economic order quantity makes the optimum analytic — total cost \(SD/Q + HQ/2\) is convex with minimum \(Q^* = \sqrt{2SD/H}\) — and its sensitivity to \(S\) shows the setup-cost-attack lever: halving the ordering cost shifts the whole curve to a smaller, cheaper batch.
Parents (1) — more general patterns this builds on
Batch Sizeis a kind of, typicalTrade-offs — Batch size is a SPECIFIC structured trade-off — a fixed-per-batch cost that amortizes against a per-item flow cost that rises, with a convex U-shaped total-cost curve (EOQ sqrt law) plus coupling-of-fate and feedback-lag riders. A computable specialization of the generic trade-off schema.
Batch Size is not Economies of Scale because batch size is a U-shaped trade-off with an interior optimum, whereas economies of scale is monotone — average cost simply falls as volume rises.
Batch Size is not Queueing because batch size is the static grouping granularity, whereas queueing is the dynamics of waiting under stochastic arrival and service that the batch decision feeds.
Batch Size is not a generic Trade-off because it is a specific, computable structure (the √(setup/flow) law, convexity, the setup-cost-attack move), whereas a generic trade-off is the bare schema that some exchange exists.