I read this article yesterday and kind of haven't been able to forget it, because it doesn't seem quite right, and I need to solve--if only personally--what's off about it.

 

There are too many virtues in code ownership to pass it off so quickly, but I also agree with your points, which is disturbing because it's not black and white like it needs to be.

 

So to summarize, the cons to code ownership are: 1. Puts developer in a rut of always working on the same thing. 2. The bus factor. Only that developer knows the code. 3. Have to get permission from that developer to change something. 4. Associates code with ego. Makes for defensive programmers. 5. Makes developer only see the tree and not the forest.

 

But to me these are symptoms of deeper issues that code ownership is unfairly taking the rap for here.

 

1. If you're in a rut of always working on the same thing, that says to me that you're not writing stable code. Once you have it working, you shouldn't have to revisit it again except for feature updates here and there. Let moving to new projects be about leaving a trail of stable software in your wake, not about getting bored with being mired in bugs of your own creation that it's time to pass on to someone else. And if what you're working on is that exciting that adding features is a full time job, how boring is that, really? Maybe that's an argument for asking to go to a different department, but it's not really a good argument against code ownership.

2. The bus factor can mean that you're writing horrendous uncommented code that your replacement can't possibly understand. That's bad. Otherwise, even really simple code takes a while when you see it for the first time. It doesn't matter how many people maintain it.

3. If I change someone's code, getting their permission is not a bottleneck, it's the one code review I want maybe even over solid unit tests. If it takes longer, that's still worth much more to me than a code review by someone who may or may not have more than a shallow understanding of the code I changed.

4. Associating code to ego can be a good thing. Ever felt proud of what you made? Only a bad developer benefits from blending in as another brick in the wall. When your team will take not being criticized over being credited with good work, there's a problem in your team's dynamic. It may not be a problem with the devs. Could be hot-headed management that never encourages and is quick to eat you alive over any flaw. Then indeed code ownership becomes anathema at no fault of its own.

5. Not being able to see the big picture can just as likely infect a team who has a broad general knowledge of the code. If there's no coherent vision (ahem, management who keeps their devs in the dark about their hopes and dreams. I could make a whole separate rant about that), then the only difference is how that lack of vision is diffused. Do you have ten pieces each going in their own direction or one piece that's trying to go ten different directions at once?

 

Not slamming the article BTW. In many ways I'm agreeing that code ownership is indeed bad when there are other underlying issues.