People can handle it better or worse, but honestly I think it's just a hard situation with no perfect answers. You're basically proposing adding process to man

People can handle it better or worse, but honestly I think it's just a hard situation with no perfect answers. You're basically proposing adding process to manage the velocity of change. A common situation, for example – some small bug is assigned to a less productive member of the team. The fast developer has to touch that area of the code for some other (often more critical) change. The fast developer sees the bug and just fixes it, or perhaps invalidates the need for that bug fix. Now the less productive member has their work undone. Claiming territory would slow down the fast developer, and also is demotivating for people who are motivated by increased code and product quality and want to bring that attitude to every bit of code they touch. You can run a smallish team with widespread improvements if you are in a situation where turnaround is fast. We're not going to run into too many conflicts if each of us finish our work and get it merged on a daily basis. But then you have that one person who takes a week on a change, and it doesn't go so well. Unless you put them in some codebase ghetto, where changes won't conflict because no one actually cares about the output. How do you manage multiple kinds of vehicles on the road? Speed limits? Minimum speeds? Passing lanes? Semaphores? There's no one right answer, and all the answers are wrong from some perspective.