The Serial Fraction

There are two ways to build the same system. You can build it as one tightly integrated piece, where every part is free to know every other part, nothing is duplicated, and nothing is abstracted that didn't need to be. The result is lean, fast, and small. But it can only be built the way it is shaped: one piece at a time, by builders who all hold the same big picture in their heads. Or you can cut the system into modules behind interfaces and build the pieces in parallel, as independent streams that only meet at integration. The result can be built by many hands at once. It is also bigger: more code, more interfaces, more duplication, and, if the builders are paid by the hour, more hours.

That is the standard accounting, and every architect carries some version of it: the monolith optimizes the artifact, the modules optimize the building. This article makes two claims. The first is that the accounting is wrong. Not in its arithmetic, but in its units: the real currency of this trade was never lines of code or man-hours, it is coordination. Fifty years of literature converge on that conclusion from different directions, and the crash course below compresses them. The second is that the trade is worth re-reading right now, because the builders are changing. The Shapes of Collaboration asked how collaborators coordinate. This article asks the reverse question: how does the shape of the thing being built decide what coordination is needed?

The real ledger

Start with what decomposition actually does. It does not remove work, it relocates it. Cutting a system into modules moves effort out of writing and into coordinating: someone must decide where the cuts go, define the contracts at each cut, keep those contracts stable while the pieces are built apart, and verify that the reassembled whole does what the intact whole would have done. None of that work exists in the monolith. In exchange, all of the monolith's work is serial, because every builder must share, or negotiate, one global context.

There is a name for this structure. Amdahl's law (1967) says that the speedup you can get from parallel processors is capped by the fraction of the job that is inherently serial. Transposed to construction, the serial fraction of building software is exactly the list above: agreement, integration, verification. No number of parallel builders compresses it. Brooks saw the human version in 1975: put n builders on a project and you create up to n(n−1)/2 communication channels, so coordination grows quadratically while writing capacity grows linearly. Past a point, adding hands slows the project down.

So the trade-off has a precise shape. Decomposition converts serial writing into parallel writing plus serial coordination, and it pays as long as the coordination it adds grows more slowly than the writing it saves. With too few modules you are bottlenecked on the one big picture. With too many, you are bottlenecked on the contracts between them. Somewhere in between sits an optimum, and where it sits depends on properties of the builders, not of the runtime.

This also settles the lines-of-code question. LOC felt like the cost of modularity because LOC was a proxy for man-hours. But what the extra code actually costs is not the typing. It is surface: code that must be kept coherent with its duplicates and verified against its contracts. Redundant code that is cheap to write can still be expensive to own. Keep that distinction in mind, the last section relies on it.

The explorer above is the ledger in one picture. The write curve falls as modules are added, which is parallelism doing its job. The coordination curve rises with the square of the module count, which is the interfaces taking their share. Their sum is a U, and the optimum sits at its bottom, fenced on the left by a wall: modules so large that no single builder can hold one. Note the two presets. Read the crash course, then come back and flip them.

The crash course: six ideas that settle the question

The monolith-versus-microservices debate reads like fashion because it is usually argued without its underlying theory. The theory exists. Here are six ideas, from 1937 to 2019, each settling one part of the question.

Stable intermediate forms (Simon, 1962)

Herbert Simon tells the parable of two watchmakers. Hora builds watches from stable sub-assemblies of ten parts; Tempus builds the same watch as one continuous assembly of a thousand. Every interruption (a phone call, a customer) makes Tempus start over, while Hora only loses the sub-assembly in his hands. Hora prospers, Tempus never finishes a watch. Simon's point is general: the complex systems that survive in nature are nearly decomposable, hierarchies of stable intermediate forms with dense interaction inside each part and sparse interaction between them, because that is the only architecture that can be assembled in a world full of interruptions. This is the deepest answer to why modules exist. Modularity is what makes construction interruptible, resumable, and parallel. A monolith is a bet that nothing will interrupt you.

A module hides a decision (Parnas, 1972)

David Parnas asked what criterion should decide where the cuts go, and answered: not the steps of the processing. Decompose by the design decisions that are likely to change, and hide each one inside a module, so that when the decision changes, the change stays inside. The interface is what the module promises to everyone else, the part that must not change. This is also the autopsy of most failed microservice decompositions: services cut along the request path decompose by flowchart, which is precisely the criterion Parnas rejected, and every change then crosses three services. Cut where change lives, not where the flowchart bends.

The org chart ships (Conway, 1968)

Mel Conway observed that a system's design copies the communication structure of the organization that builds it: four teams building a compiler will produce a four-pass compiler. Half a century of evidence has upgraded the observation to a law. Colfer and Baldwin reviewed dozens of studies and found this "mirroring" of technical and organizational structure across industries. Cataldo and Herbsleb located the failure mode: defects and delays concentrate where the code is coupled across a team boundary, where the architecture demands coordination that the organization does not supply. Architecture and organization are the same design problem seen from two sides. You cannot choose them independently, only which one leads.

Boundaries are priced in coordination (Brooks, 1975 and Coase, 1937)

Brooks explains why coordination is the quantity to manage; Coase explains where to put the boundaries. The Nature of the Firm asks why firms exist at all if markets allocate so well, and answers: transaction costs. When coordinating across the market is expensive, you pull the activity inside a firm, where coordination is informal and cheap. A module boundary is a firm boundary in miniature. Inside a module, parts coordinate freely. Across modules, they transact through contracts (interfaces), which are precise, and priced. Draw the boundary so that the expensive conversations happen inside it, and only cheap, contractual ones cross it.

Modularity is an option (Baldwin & Clark, 2000)

Design Rules is the economics of the whole trade. Modularity is an investment: you pay a fixed cost up front (the "design rules", the interfaces everyone must obey) and what you buy is options. Each module can then be improved, replaced, or run as several competing experiments, independently, without renegotiating the whole. That is why the modular version is bigger and often initially worse than the integrated one, and why it wins anyway when uncertainty is high: the option value outgrows the architecture tax. Their design-structure-matrix tooling also made coupling measurable. MacCormack's studies of open-source and proprietary codebases showed that the architecture a system actually has is an empirical object, often quite unlike the diagram on the wall. The extra code is a premium. What it buys is the right to change your mind one module at a time.

Size modules to heads (Team Topologies and DORA, 2018–2019)

The modern practitioner synthesis puts a limit on the cutting: cognitive load. A component's right size is what one team can hold in its collective head; beyond that, the team degrades into ticket-routing between sub-specialists. Team Topologies turns Conway's law from a threat into a tool with the "inverse Conway maneuver": shape the organization to induce the architecture you want, since the mirroring will happen anyway. The DORA research in Accelerate supplies the empirical anchor: loosely coupled architecture is among the strongest predictors of software delivery performance, because it is what lets teams build in parallel without asking permission. A module's right size is set by the head that must hold it. The builder's head, not the machine's.

Where the coordination lives

One clarification before re-running the ledger, because it changes what "architecture" means. It helps to name three layers in a system's description. L0 is the big picture: stakeholder intent, what the system is for, which trade-offs are acceptable. L1 is the system and software requirements: what each part must do, and the contracts between the parts. L2 is the code.

Everything the ledger prices (the agreement, the interface contracts, the criteria that integration is verified against) lives at L0 and L1, not at L2. In the vocabulary of the Shapes article, the environment through which parallel builders coordinate is the requirements layer, and an interface contract is a signal left in that environment: written once, read later, by builders who never meet its author. The specification is the pheromone. The code is not the coordination medium at all. It is what accumulates where the coordination pointed.

Three consequences follow. Parallelism is decided before the first line of code is written: it is fixed at the L1 cut, and no effort at L2 can recover a bad one. Integration failures are L1 failures, two contracts that never actually composed, but they surface at L2, which is the most expensive place to discover them. And "the code is the documentation" fails precisely for parallel building: builders working apart need the coordination signals to live above the code, otherwise they have nothing to coordinate through except each other, which brings back the monolith's serial bottleneck.

This is the reframe worth keeping: architecture design is environment design. You are not drawing the system. You are building the medium its builders will coordinate through.

Re-running the ledger with agent builders

The Shapes article ended on a method: when the collaborators change, re-run the framework, because parameters everyone treated as constants come loose. The classic ledger was priced for human builders: writing is expensive, builders are scarce, and a builder's capacity is a career's worth of context. LLM agents reset all three, and the resets pull in different directions.

Writing cost collapses. The old equivalence between LOC and man-hours simply evaporates. Redundant code, duplicated logic, three parallel implementations of the same module: all nearly free to produce. The classic argument against fine decomposition (more code, more hours) is gone.

The capacity limit survives, in new units. The cognitive-load rule does not disappear. A module should fit in a context window the way Team Topologies says a service should fit in a team's head. The context window is the new team size, and it bounds how coarse your modules can be, exactly as team cognition used to.

Cheap writing also revives the monolith. If regenerating a subsystem from its specification costs almost nothing, some software becomes disposable, and the option value that justified the architecture tax partially collapses. Options are worth buying when rework is expensive. When rework is nearly free, the tightly coupled monolith becomes rational again for anything small enough to regenerate whole.

One thing does not move at all. Interfaces still have to be agreed. Integrations still have to compose. The assembled system still has to be verified, and the scarce resource in that loop is increasingly the humans doing the checking. Writing was never the serial fraction; now it is not even a noticeable term. Verification is the new serial fraction, and it is what the architecture must now be designed to minimize: the smallest set of contracts that lets everything else run in parallel.

Now go back to the explorer and flip the preset from Human team to Agent fleet. The write curve drops to the floor: writing no longer matters at any module count. The capacity wall moves right: modules must shrink to fit a context window. And the one slider the preset does not touch is the cost per interface, because coordination did not get cheaper. Watch where the optimum lands: on the wall. For human builders it paid to decompose finer than the wall, because parallel writing still bought time. For agent builders it does not. Decompose exactly to builder capacity and not one cut further, because every extra cut buys nothing (the writing is already free) and multiplies the interfaces you must verify.

One more parameter came loose, and it may be the biggest one. For fifty years Conway's law ran in one direction: the organization was the given, the architecture mirrored it, and the "inverse Conway maneuver" meant a slow, painful re-org. An agent fleet is a programmable organization. You can spawn whatever communication structure the target architecture needs, per task, in seconds, and dissolve it afterwards. Architecture can finally lead, and the organization can follow, at zero cost.

So, the thesis in full: parallel building was never limited by how fast we could write. It was limited by the serial fraction: agreement, integration, verification. Builders that write for free do not resolve the old trade-off between the lean monolith and the parallel modules. They strip it down to what it always was: a negotiation with the serial fraction, settled at L1, in the design of the environment the builders coordinate through.

The curriculum

The crash course above is a map, not the territory. Here is the reading path, in the order that builds best.

1. Herbert Simon, "The Architecture of Complexity" (1962): why hierarchy and near-decomposability are what buildable complexity looks like. The watchmakers are in here.
2. David Parnas, "On the Criteria To Be Used in Decomposing Systems into Modules" (1972): the correct cutting criterion, in eight pages.
3. Fred Brooks, The Mythical Man-Month (1975), chapters 1–3: the coordination arithmetic of adding builders, unchanged in fifty years.
4. Mel Conway, "How Do Committees Invent?" (1968), then Colfer & Baldwin, "The Mirroring Hypothesis" (2016): the law, then the evidence for it.
5. Ronald Coase, "The Nature of the Firm" (1937): optional, and the deepest single answer to why boundaries exist and where they belong.
6. Baldwin & Clark, Design Rules: The Power of Modularity (2000): the economics. Dense, so start with the introduction. Pair it with MacCormack, Rusnak & Baldwin, "Exploring the Structure of Complex Software Designs" (2006) for coupling made measurable.
7. Forsgren, Humble & Kim, Accelerate (2018) and Skelton & Pais, Team Topologies (2019): the empirics and the practitioner synthesis.
8. Last, the fashion cycle, now legible as applications of the above: Fowler's "MonolithFirst", Tilkov's "Don't start with a monolith", and Shopify's "Deconstructing the Monolith".

And where this series goes next. Each of the loose threads above deserves its own article:

• Verification is the new serial fraction: what testing, review, and acceptance become when writing is free and checking is not.
• The programmable organization: running Conway's law backwards with agent fleets, per task, at zero re-org cost.
• The context window is the new team size: granularity rules for agent-built systems, and what "fits in one head" means when the head is measured in tokens.
• Disposable software: what survives of modularity's option value when regeneration costs less than modification.
• Finding the real architecture: design structure matrices in practice, measuring the coupling you have instead of the coupling you drew.

A monolith and a fleet of microservices are answers to the same question: how much serial coordination will you pay to unlock parallel work? The answer was never in the code. It was in who is building, what they can hold, and what a unit of their work costs. Those were constants for fifty years. They aren't anymore.