Every project is a distributed system

There’s a result in computer science about keeping the same information on many machines. When the machines can’t reach each other, each one has to choose: stop and wait until they can agree, or carry on and risk disagreeing. You can’t have both.

A big project works the same way, except the machines are people. Everyone carries their own copy of the project in their head: what’s been decided, how it’s meant to fit together, who’s doing what. Those copies are never quite in sync. Someone was asleep. Someone was buried in something else. Someone started yesterday. A decision made this morning hasn’t really happened yet for the person who hasn’t heard about it.

So whenever a decision changes, you face that same choice. Stop everyone until they catch up, which keeps things consistent but slow. Or let people keep working, and accept that some of what they build will rest on something that’s no longer true.

What makes it harder is that decisions lean on each other. Change one and others have to shift to make room, sometimes a long way from where you started. A part gets built carefully, faithful to an earlier choice. The choice changes. Now the careful part is wrong, and so is whatever sits on top of it. Nobody made a mistake. Being faithful to the past is just what drifting looks like from the inside.

It’s only an analogy, of course. The result is about a particular kind of machine, and a team isn’t one. But the feeling is the same.

There’s an old image of sailors who have to rebuild their boat while they’re at sea, one plank at a time, never able to pull into harbour. That’s what a large project is like. You can’t stop everything to make it consistent. You can only decide which decisions matter enough to stop for, and write those down where everyone can find them.