Skip to main content

← All writing

"Don't Touch My Code" Is Not a People Problem

You're deep in a change. You've held the whole module in your head: every function, every edge case, the reason the retry logic looks the way it does. Then you open the file, and someone else has been in it. The shape is different. Your model no longer matches the code.

A developer in a 2016 study put it exactly:

"You have your line of thought interrupted by another person, you are developing, and you have already imagined what will happen, every function, every attribute, then when someone else changes, that ends up confusing a bit."

Every developer recognizes this. The usual diagnosis is a people problem: one person is too possessive, another too careless, the team needs more discipline. So managers reach for practices. Code review. Pair programming. A shared-ownership agreement stating that no one owns anything.

The practices don't resolve it. They can't. The conflict isn't produced by the practice. It's produced by the structure.

Everyone asks first, whatever the rule says

That study, by Monteiro and colleagues, interviewed 19 developers across three companies about shared code ownership. The companies ran different official policies, but the developers described the same habit. Across all three, they consistently checked with whoever wrote or maintained the code before changing it.

At one company, the owner had mandated outright collective ownership. In a developer's words: "We're being forced to work with collective code ownership." On paper, no one needed permission to touch anything. The developers there described asking anyway.

The researchers read this as an adaptation for less-experienced developers: people who are still unsure about unfamiliar code, checking before they touch it. That reading fits the interviews. So does another one.

What the developers keep pointing to is risk: the danger of changing code they don't fully understand. The paper locates that risk in a knowledge gap, and a knowledge gap is what a component structure manufactures. The study can't isolate structure as the cause, not from 19 interviews, and it doesn't try. But the pattern it records is the one the structural reading predicts: where knowledge is siloed by component, consulting the owner is how a developer manages the risk of a change, and they reach for it even when the official policy says they don't need to. The rule says ownership is collective. They act as if it isn't, because the knowledge isn't.

Why better practices don't help

Code review, pair programming, documentation mandates, and rotation schemes: each one manages the risk of someone changing code they don't understand. Each is a response to a symptom. They treat the unfamiliarity as a fact of nature and work to contain its damage.

None of them asks the prior question: why is the code unfamiliar in the first place?

It's unfamiliar because of how the work is divided. When teams are organized by technical component (the API team, the database team, the mobile team, the payments team), each team sees only its slice. A customer feature that crosses those slices crosses several teams' knowledge boundaries at once. The familiarity boundary is the organizational boundary. Nobody sat down and decided to make the payments team the only people who understand payments. The structure decided it.

The owner is protecting the system, not the territory

Knowledge concentrates twice. First, at the component boundary, one team owns the payments service, and no one outside it has reason to learn the internals. Then, inside that team, onto the one developer who has touched the code the most. Call her the owner, and it sounds like territory. It isn't. She is the only person who can see how a change ripples through the component and out into the parts that depend on it, which makes her the only person who can change it safely. And she knows it.

So when someone edits the module without asking, her defensiveness isn't ego. It's an accurate reading of the risk: she can trace where the change lands, and they cannot. The organization made her the single point of failure. So she guards the code. Her instinct to protect it is the system defending itself through the one person positioned to do it.

This is why removing the owner doesn't help. Mandate collective ownership, and the context doesn't redistribute: only the safety mechanism disappears. The code is still understood by one person. Now everyone is allowed to break it.

The defect data points in the same direction. In a 2011 study of large Windows components, Bird and colleagues at Microsoft Research found a strong relationship between ownership and defects: components with concentrated ownership had fewer of them, and components with many minor contributors (people who had touched the code only a little) had more. The common interpretation is that shared code causes bugs. But the study measures ownership distribution, not organizational structure, so the drivers of the correlation remain open. A structural reading fits the numbers: when many people keep changing code across knowledge boundaries they don't fully hold, defects rise. On that reading, the boundary is doing the damage, not the sharing.

There's a sharper version of the same dynamic. Developers in the study described code criticism turning personal: meetings where "I saw your code, [it] was very poorly done" set off open conflict. When the code is yours, it can fuse with your professional identity. Criticism of the code reads as criticism of you. On a team that shares context, the same comment is merely operational: "Here's a better way; let's change it."

What changes when the team owns the feature

Craig Larman and Bas Vodde draw the contrast between feature teams and component teams: a feature team is organized around end-to-end customer features rather than technical layers. The bigger change lies in what each team owns, which resets what failure means, what a change risks, and how far it travels.

A component team owns a part: the payments service, the API layer. The part holding to its contract is what success means, so failure is local: my component broke. A customer feature spans many parts, so it can fail for the user while every component still passes its own tests, and no one owns that failure. The risk of a change is measured against the part, not the customer, and the responsibility for containing it falls to the one person who can see past the part. Ownership narrows to them. "Don't touch my code" is the gate.

A feature team owns the outcome: the customer feature, end-to-end, across whatever components it touches. Failure is the customer not getting that outcome, and the team owns it, with no "my part works" to hide behind. Because they own the whole path a change travels, they can see where it lands. Ownership stays with the team rather than narrowing to a person, and the need for a gate shrinks because no one is the sole keeper of the context. The conflict changes its words: "Let's pair on this, I'll show you the context."

The shift is not about persuading developers to be more generous. You don't fix this with a culture deck or a shared-ownership pledge. You change the structure so that sharing is safer, because the team now has the context that makes sharing productive rather than dangerous.

Back to the interrupted developer

Return to the developer from the study, the one whose line of thought broke when the code changed under him. In a component team, that interruption is real damage. Someone altered code he had a model of, and they didn't share the model. He has to reconstruct what they were thinking; they have to reconstruct what he was thinking. The structure set up the collision.

Put the same developer on a feature team and the experience changes, though nothing about the practice did. The code that changed isn't alien, because the team built it together. The interruption isn't a rupture, because the context was already shared. Same person. Same moment as someone else in the code. Different structure, different outcome.

"Don't touch my code" is not a confession of ego. It's a measurement. It tells you how much context lives inside one person and how little of it is shared. The fix was never to get developers to say it less often. It's to change the structure that gives them a reason to say it.

The next time you hear it, don't ask who needs to be more collaborative. Ask what the structure made them protect.

Sources

Slovenská verzia →

How this shows up in a real organization →

All writing →