I was reading this great article titled, “The Quiet Crisis unfolding in Software Development”. I found it to be a great read. You should really check it out. But, there was a part of the article that I found interesting:
Your employees like working for you—right?—which means turnover should be low. Don’t optimize for developers leaving which should be the uncommon scenario. For best results optimize for the common scenario.
Optimizing for the common scenario means giving developers primary ownership of portions of the code base and not allowing other developers to change that code without approval from the primary owner. This results in higher productivity since any given developer is more likely to be familiar with the code in which they will typically be working.
As someone who pair programs all day, I completely disagree with this and think it’s dangerous. I can talk about the bus factor, but I also think that staying on one project makes developers unhappy.
The main reason I’ve left companies is because I got sick and tired of knowing what I’ll be working on if I work there for the next 5 years: The same thing I’m working on today. The truth is, it raises morale to work on something new once in a while.
Think about it: When you’re on an interview and you’re asked, “Where do you see yourself in 5 years?”, are you supposed to answer, “Pretty much where I am right now”? No, that would be a terrible answer and the interviewee wouldn’t want to hear it. They want to hear some ambition, about how you’re going to grow with the company, and how you’d be a good investment.
When you have a culture of always keeping people on the same project, you’re sending the message that they’ll always be trapped doing the same thing day in and day out unless they find another job. Nobody wants to keep working on that decade old code base, even if they created it. That’s about 5 generations of web frameworks and techniques. If you keep working on the old code base, your skills are going to become stale and irrelevant.
not allowing other developers to change that code without approval from the primary owner
I also think this is a dangerous policy. First of all, it creates artificial bottlenecks in the system. If I need this bug fix in some code I depend on but the guy who approves the change is on vacation, my progress just became blocked.
Second, this psychologically encourages peoples egos to be tied to their code. “You can’t touch that because that’s mine” / “You can’t critique that because I made it” / “You can’t improve that because it’s mine“. This is unhealthy and uncollaborative. I know it’s annoying when a novice comes into your code base and commits something that doesn’t follow your coding style or even introduces a bug. But, the reaction to this shouldn’t be to quarantine off all code. The reaction should be to teach this person and work with them to improve the (not your) code base in the future.
Third, it makes developers care more about their piece of the puzzle than the big picture. If there’s a problem somewhere else, they’ll only be interested in it if it directly effects their code.
Fourth, siloing code tends to go hand in hand with siloing knowledge and skills. Some code bases are going to be high quality, others are going to be poor quality. And if the owners of each don’t interact with each other, that’s the way it’s going to stay. In a true vacuum, this might be ok, but eventually some of the good code will depend on the bad. This will cripple your company’s ecosystem of software.
A better approach is a policy that everyone is responsible for all code bases. There should be no barriers to making an improvement to any code in the ecosystem. Yes, developers will have varying skills and mistakes will be made. But if you also have a policy that it’s ok to make mistakes as long as you learn from them, the lower skilled developers will improve their skills faster than being left to their own devices.
One thought on “Code ownership is a bad thing”