Ask HN: Code territoriality – good or bad?
I have always read that people being too possessive of some section of the code base that they wrote is a bad thing, and should be avoided. Almost universally it is said to be bad for organizations that one programmer owns one particular module, particularly in larger organizations.
On the other hand, my company previously had strong code ownership where a small team owned each module, and rearranged a few months ago where we have collective code ownership.
The problem is that so many of the pull requests I see are people who have little understanding of the domain specificities of our old module, and the architecture of it. I see drive-by pull requests which, if they went in as is, would look very sloppy in this clean module we spent so long building.
Is code ownership always bad? Martin Fowler has an interesting dynamic he calls weak code ownership - a team (or person) is responsible for a module, but other teams can change it, although larger changes usually would involve consultation.
I've always heard the notion that being possessive or territorial about a section of code is bad. But our old team spent over a year building a nice clean module, and the pull requests coming in could do substantial damage in one merge to something we spent over a year making nice and clean. I don't block people from doing work but I do hold up pull requests touching our old module until they clean up what they're doing.
Also - some of what is coming in is from consultants who might not be around in six months, and are a drive-by pull request where they may never touch our module again. So spending time educating them and so forth would be a waste of time. The handful of people who will be working with the module on a more ongoing basis I have spent more time educating, helping and bringing in.
https://www.martinfowler.com/bliki/CodeOwnership.html
(also -
https://signalvnoise.com/posts/3023-why-programs-become-territorial
https://www.freecodecamp.org/news/why-code-ownership-sucks-and-you-should-never-work-somewhere-that-practices-it-b8fc1c694074/
https://www.coderhood.com/12-reasons-avoid-individual-code-ownership/ )
I for one believe that current approach of no code ownership is one of the main contributors to terrible quality and performance of modern software. People are just routinely modifying code they know very little about, it's pure insanity in my opinion. Let's hire 10 writers to work on the same novel where they're all allowed to make changes to any part of it, and see how good the result it...
The main reasons companies prefer this way of working is the bus factor. Not even being hit by the bus per se, but just having only one expert on a given piece of the system gives him leverage in negotiating pay and working conditions - and most managers hate workers who are not powerless cogs (it' much easier to manage cogs than people), and they will sacrifice efficiency and product quality to reduce people to such status.
There are a companies in niches where software quality and performance cannot be skimped on and they sometimes don't do "shared" code ownership (the alternative is to still do "shared" ownership and compensate via ungodly amount of testing to catch any issues before release - as far as I understand this is the approach in large companies that do critical embedded software - auto, medical etc.). Essentially I believe that code ownership is mostly practiced in small boutique companies which produce performance-sensitive software - somebody like an audio plugin maker etc. Everybody else, incl. web startups, went the way of the moloch via shared code ownership so that owners' and managers' jobs are easier.
I personally think your most senior devs should collectively “own” less than 10% of the code, otherwise they become bottlenecks of both feature development and career advancement.
Outside of those you want a bus factor on everything else. Which also helps control meeting size and coordination. (I can’t have this meeting at 2:00 because Steve is in another meeting at that time.)
I personally think code ownership is vital. I've called it feudalism at times. Even if you're hiring a freelancer, they should own their part.
I've taken over lots of code from other people. Ironically the ones where there is no ownership are the worst - they tend to be overdocumented, overengineered, declarative and non-flexible. Whereas undocumented code from freelancers who loved coding was really easy to continue on. Caring about what you makes for better code than not caring.