Collective Code Ownership

Giving code an owner used to look like the obvious arrangement. Split the system into areas — one person on payments, another on notifications — and responsibility gets clear while collisions get rare. The owner knows that area better than anyone, so changes there land fast.

The arrangement fell apart whenever the owner wasn't around. A one-line wording change on the payment screen would sit for a week because the person who owned that screen was on vacation. If someone else reached for it, the answer was usually "leave it, I'll look when I'm back" — and since a few outside edits had broken things before, that answer was hard to argue with.

Given enough time, the boundaries hardened. Everyone knew their own area deeply and the next one not at all, so work got assigned by whose area it was rather than by who had capacity. A queue would pile up in front of one person while the desk beside them sat idle, and nothing could move across.

Collective code ownership erases those boundaries on purpose. In exchange it demands something else: evidence, built in advance, that a stranger to the code can change it without breaking it.

The rule itself fits in a sentence. Anyone who decides a file needs to change opens it and changes it, without asking permission from whoever has been looking after that area.

Three things have to be in place for that rule to hold up.

1. Automated tests — machinery that checks whether the code still behaves, instead of a person checking by hand. There are layers, from a unit test that isolates a single function to a test that loads the screen and walks through a real flow. This is where the evidence comes from that you touched unfamiliar code and didn't break it. Open untested code to collective ownership and editing someone else's area is just a gamble.
2. Continuous integration (CI) — merging everyone's changes into the main line several times a day and running the tests automatically on every merge. Short intervals are what keep conflicts small when two people touch the same file. Hold two weeks of work and then merge, and the job turns into choosing whose code survives.
3. Code review — a colleague reading the change before it merges. It isn't a permission gate. It's a place where someone who knows the history of that area points out what the author missed.

One more thing gets agreed on: a shared style for writing code, covering everything from indentation to how variables are named, so that anything reads the same regardless of who typed it. When every area looks different, reading someone else's code eats the whole budget before any editing starts.

This practice doesn't arrive alone. It comes bundled with the other practices from the same method.

Pair programming puts two people on one screen writing code together, and rotating the pairs means an area only one person understands never forms in the first place. Declare collective ownership while exactly one person actually knows the code and the rule lives only in a document. Mob programming puts the whole team on one task, which is how teams open a new area nobody understands yet — one day spent getting everyone the same picture.

Simple design pairs with it too. Build only what's needed now and the code stays small, and small code can be read by a newcomer in an afternoon. Structure laid down in advance for requirements that haven't arrived is the opposite: nobody but its author can say why it's shaped that way, so it quietly becomes an area only that author can edit.

On the organizational side, the same practice reads as a way to reduce key person risk — the exposure a company carries when one person's absence stops work. In a codebase that exposure almost always traces back to divided ownership. If requests for one area backed up for three months after a resignation, that's not a fact about the person; it's the result the ownership model produced.

"That's payments, so I think we need to ask Theo."

A sign that collective ownership exists in name only. The code is open, but one person understands it, so in practice nobody can change it.

"It's collectively owned, just fix it and put it up. I'll review it."

Don't ask first, change it and get checked after. That inversion of order is the entire practice.

"We can't open this part up yet, there are no tests on it."

Not a refusal of the rule but a statement that its precondition is missing. It usually comes with an offer to add the tests first.

At Pagedeck the change that made this real was the expiry notice on document share links. Noa filed a request to reword it, and Theo, who had built that screen, was out that week. Under the old arrangement it would have waited. Instead another engineer made the edit, the tests passed, and it shipped that day. Theo read the change history when he got back and tightened one line.

Mia says the practice changed how planning meetings run. The team used to sort the backlog by whose area each item belonged to; now they sort it by who has room. The trade is visible in the numbers — review time went up noticeably, and the team treats that as time bought back from waiting.

The most common misreading is that collective ownership means nobody is responsible. With no owner, the worry goes, there's no one to answer for a break. What actually happens is that ownership moves to the whole team rather than disappearing, so whoever finds something broken becomes the person who fixes it. Leave the misreading in place and the team drifts toward "not my area, I'll just report it," and problems sit known and untouched for months.

The second is that the rule removes rules. "Anyone can change anything" sounds a lot like "anything goes." In practice the rule count goes up. For an edit by someone unfamiliar with the code to be safe, tests and style agreements and review all have to be tighter than they were under divided ownership. Erase the boundaries without that groundwork and within a few weeks there's a log of people breaking each other's work — which sends the team straight back to handing out areas again.