TL;DR If you see that teams "reject" the (part of) codebase, working with it lowers their engagement level, they have neither energy nor will to tackle its challenges, it's very rarely the matter of codebase's size. Sober-minded engineers just do not want to have anything to do with crappy code, especially if they don't feel responsible for its "crappiness". What they need is not their nametags pinned to particular mounds of dung, but a viable, credible & feasible strategy to dispose it.

Code ownership problem is almost as old as teaming in software engineering. At some point it became clear that teams can't grow beyond some point (~12 people max) w/o bogging down their efficiency & that conclusion resulted with an open question:

What is the most reasonable way to split / share large codebase between several teams?

Should a particular team "own" its dedicated slice of the pie? How should the slicing be done? Layer-wise? Domain-wise? Technology-wise? Or maybe teams should bid (compete?) for change orders within different parts of the codebase & it should be a product/vision owner who decides who does what at this point? Should the ownership be strict & regulated or loose & open for voluntary collaboration?

Obviously one could imagine various models working well for different kinds of organization, but what I find particularly interesting is the fact that basic team assignment to chunk of code is frequently mistaken with another kind of code ownership:

Measure of team's level of engagement (while working on particular piece of code) & capability of introducing a change (into this piece of code) in safe & efficient way, w/o unwanted, unpredictable effects.

In simpler words - if the team struggles with the change, doesn't know how current functionality works (hence has lower velocity), causes regression, fails to tame technical debt -> it's frequently perceived as an issue of insufficient ownership over the code. And this perception is linked with few very dangerous misconceptions:

"It's too much"

"If N teams are struggling with full codebase, why not split it so each of them will cover 1/N. They will be more focused, it will be easier for them to grok through their part only."

Even if this may sound quite reasonable, it's rather far from truth. Developers do not memorise the code, they don't learn it by heart - they READ it, use modern developer tools to NAVIGATE it, TRACE execution paths & MAP what they've learned on their accumulated domain knowledge / application architecture knowledge.

That's why it's so important to:

• use ubiquitous language (& descriptive naming)
• follow both single responsibility & Open/Close principles
• avoid "hidden" side effects
• follow set conventions
• maintain clear & "shallow" dependencies (ref.: Law of Demeter)

Developer can grok & comprehend a vast "codespace" if it follows industry standards & clean code principles. Actually, for majority "the more is the better" as the variety helps to avoid predictability & boredom.

Narrow ownership = higher accountability

"But if particular module is owned only by Team X it's far easier to ask & demand (for higher velocity, gradual improvement, etc.), isn't it?"

Well, clearly they'll realise that if they don't clench their teeth & start cleaning their cesspool then no-one will do it for them ... But based on my past experience the typical reaction was an "unwanted child syndrome" - teams were doing everything they could to avoid dealing with "poisonous" code, including: hiding it behind excessive layers of abstraction, walking around existing problems, etc.

Why so? Because they have been GIVEN (/assigned) this ownership. They didn't feel truly responsible, as they didn't consider their past work "guilty" of current state of code. People rarely see any point in suffering for someone else's "sins" (especially if in their perception the piece of code given to them is the worse - 90% teams will claim that :>).

Narrow ownership = less constraints / dependencies

"But isn't clear ownership over module / component supposed to empower the team? They can come up with their own technical solutions, battle-prove independently their way of fixing problems w/o having to synchronise / coordinate with others ..."

Sadly, this beautiful theory is very far from reality. Ownership issues are in the first place one of the first indicators of underlying problems with large codebase quality - uncontrolled dependencies, over-complicated & tangled business logic that leaks out into every corner of the system, etc. As a consequence, any kind of split would be blurry & fuzzy enough to cause a lot of confusion & disastrous "butterfly effects" after each deeper refactoring change.

Of course it would be matter of time to have some "natural mechanisms of defence" developed (new boundaries) - BUT with all the consequences of Conway's Law - for architecture, communication & at last but not least - feature development efficiency.

Narrow ownership = more competitive environment

"But aren't software engineers ambitious & highly competitive creatures? Wouldn't such an element of "gamification" push Team X to prove they can do better than others?"

Yes, in fact they are. But they are not that easy to manipulate :) It's a matter of innate aversion to reading other people code / adopting other people's "flawed" (quotation marks are here for a reason ...) way of thinking. In software engineering there are some many ways of solving each problem that once we "fall into our own tracks", jumping into different solution model requires a lot of maturity, goodwill, openness and ... modesty. Many people just (more or less) unconsciously trigger their own defensive reaction mechanisms ("what kind of shit is that?!") that are blocking them completely.

Common mean no one's?

"Even if we agree that split ownership is wrong, why is the shared one supposed to be better? If there's no way to convince few people to fix their stuff, how can it be achieved for the larger group (& larger codebase)?"

It's a matter of the power of community. The larger the community, the greater its causative power. And the best motivation for people to improve things is to trigger the 1st effort & demonstrate the effect. Clearly:

• the bigger the impact, the more visible the effect will be
• in larger communities, even if everyone contributes just the drop (relatively insignificant effort, if compares with overall working capacity), the aggregate effect will not be possible to overlook
• local efforts within teams would be much less tangible than focused, joint force in a place that demands most attention / cause the most pain - obviously it doesn't mean that several teams should work on a single class or even module: it's just that bad engineering scales well :) so faulty practices tend to be very infectious - removing them one by one gives a clear sense of progress & improvement

Pic: © Sylverarts - Fotolia.com