Is individual code ownership important? [closed]

Question

I'm in the midst of an argument with some coworkers over whether team ownership of the entire codebase is better than individual ownership of components of it.

I'm a huge proponent of assigning every member of the team a roughly equal share of the codebase. It lets people take pride in their creation, gives the bug screeners an obvious first place to assign incoming tickets, and helps to alleviate "broken window syndrome".

It also concentrates knowledge of specific functionality with one (or two) team members making bug fixes much easier.

Most of all, it puts the final say on major decisions with one person who has a lot of input instead of with a committee.

I'm not advocating for requiring permission if somebody else wants to change your code; maybe have the code review always be to the owner, sure. Nor am I suggesting building knowledge silos: there should be nothing exclusive about this ownership.

But when suggesting this to my coworkers, I got a ton of pushback, certainly much more than I expected.

So I ask the community: what are your opinions on working with a team on a large codebase? Is there something I'm missing about vigilantly maintaining collective ownership?

Answer 1

I believe that Team Ownership is much more beneficial in the long term.

You just need to look at the following 2 scenarios to understand why concentrating knowledge in minimum numbers of people is less than ideal:

• Team member meets unfortunate accident
• Team member meets better employment opportunity

Naturally, the person/people who write particular sections will have greater knowledge of it, but don't give in to the temptation to make them the sole silo of knowledge. Silos will give you short term wins by long-term pains.

Just because you don't have individual ownership of sections of code, since you wrote it, doesn't mean you will not still have the aspects of "pride in your creation", etc. I don't believe having team ownership will greatly diminish any personal feelings of ownership of code written.

Answer 2

Ultimately, the team owns the code. But for all of the reasons you mentioned, our software team has designated individual authors for specific portions of the code. Each author has primary responsibility for their portion of the code, and secondary responsibility for the code base as a whole.

If a problem with a part of the code base surfaces, I try to go back to the person who originally wrote the code for a fix. There is, of course, nothing preventing other team members from applying a fix; all team members are expected to be familiar with everyone else's code. But we always try to get a fix from the original author first. After all, they wrote the code; they are the one most familiar with it.

I have worked in team environments that, because people didn't feel a sense of ownership in what they wrote, they weren't compelled to write excellent code, but merely average code.

Answer 3

While I agree from a business stance on reasons to spread the knowledge about the product; reality is that an individual focusing their efforts on a given area of anything will, over time, become much more versed in the given area.

To ignore this is to ignore science. The brain unfortunately is unable to retain everything it encounters. It recalls what is valid and valuable at a given moment yet even that storage diminishes over time.

I would tend to agree with you that ownership to a specific module or compartment within the larger code base will generally produce better results. Would someone leaving without any notice hinder the success? Certainly. But pretending that everyone within the team should have the same amount of knowledge with regards to the code base is naive and does nothing to better the code; it attempts to protect the code. Protecting the code is the role of the business for obvious reasons. The lengths of effort a business will go to in protecting the code can often become detrimental just the same.

You don't make sure every player on your team can play quarterback do you? I would argue that making sure ever team member has a stake across the code base is along the same lines as trying to get every player within your team to play quarterback at a satisfactory level...it does not add up. Do you have backups? Sure you do...but team members should have an identity within the team. Believing everyone is the same is asking for pain of a different sort...

Answer 4

I don't know that individual code ownership is a good idea. At least not in the sense that people can say "This is my code, and I'll do what I want with it". Maybe it's better to say that you should have individual code managership: the code should be owned by the team, but there's one particular person the team delegates responsibility and authority over it to.

The reason for this being that if it's everyone's responsibility, then it's no one's responsibility.

Answer 5

I would espouse team ownership over individual for the following reasons:

• Code consistency over the entire project
• Promotes discussion of code, which always leads to better, more vetted solutions
• If one team member is out sick (or worse), an entire section of code is not subject to delays
• Team members can work on all parts of the project, which serves to make code review built into the development process

Answer 6

Specialization is fine - for a large codebase this may in the long run save quite a bit of time of communication - but ownership isn't.

What I mean, is that the attitude should be that the team has a bug, and nobody should say that "oh, only X can touch that code, so it is not my problem". If you are part of the team, it is also your responsibility to fix bugs in the whole code base if you can, and do it properly. Person X may be the best choice to do so, but anybody should be expected to do so if they had to do it. This naturally requires the code to be written in a way that allows and invites team members to work with it. Having gnarly code will prohibit this, so strive for crystal clear, simple code, since that allows most developers to work with it. You may want to go with peer review to keep it that way.

Answer 7

I have to disagree with you: team ownership of a codebase is a much better option than individual ownership.

The obvious downside to individual ownership is that if something happens to one employee (get fired, retire, fall sick, etc.) then unless he/she wrote really clean code, it'll take a while to for somebody else to adopt that person's code, especially if they also have to manage their own code.

They're also just too many tools that make team ownership easier. Code reviews, source control – these are things that encourage team involvement throughout the entire codebase. Besides, how do you assign a particular part of a codebase to just one person? Do you just say that only this person can modify this file?

Finally, I think that if one part of a codebase breaks, its too easy to blame the person who was responsible for it, and that just causes more problems.

Answer 8

I think you need both, because there is a tension between both approaches.

If for any piece of code there is only one person who can work on it, that's really bad in the long term for the company, especially as/if it grows, because each developer becomes a point of failure. On the other hand, individual code ownership (hopefully) enables faster delivery time, because developer generally prefer that approach (incentive), because the developer knows the code very well, etc... There is also a time issue: it should be possible to reallocate developers on specific projects depending on business needs, but if you do it on a daily basis, that's horrible (if only because developers hate it, but also because the switch cost is just too heavy, and you spend most of your time doing nothing).

IMO, one role of a manager is to find a good balance between both. Code review, coding standards, standardize on a set of tools should also help diminishing the poinf of failure issue. After all, the main point of maintainable code is to tackle this issue.

Answer 9

I think collective code ownership is incomparably better than individual code ownership.

I'm not that bothered by the truck argument - in an individual ownership model, the loss of an owner is expensive in terms of the time needed for someone else to take over, but the event is rare enough that the amortised cost is low.

Rather, i think collective code ownership leads directly to high-quality code. This is for two very simple reasons. Firstly, because the painful truth is that some of your programmers are not as good as the others, and if they own code, that code will be poor; giving your better programmers access to it will improve it. Secondly, code review: if everyone owns the code, everyone can review it and improve it; even good programmers write sub-par code if left to their own devices.

I say this based on experience in my current project. We aim to practice collective ownership, but there are some bits of the system which have become specialised - me and another guy are de facto owners of the build system, for instance, there's a guy who's doing most of the work on the incoming data feeds, another guy working on image import, and so on. In several of those areas (particularly, i have to confess, in my area!), the code quality has seriously suffered - there are mistakes, misconceptions, kludges and hacks that would simply not survive the attention of other people in the team.

I note that you could gain some of the benefits of collective code ownership by having individual code ownership where the ownership of a particular bit of code moves between different programmers regularly (say, every three months, or every release - perhaps even every iteration?). A programming equivalent of crop rotation. That might be fun. I'm not going to try it myself, though.

Answer 10

I don't think team code ownership is as important as having multiple contributers understand the basic architecture of the prevailing subsystems.

For example, we have a couple of guys on our team that make administrative web pages for our server products. We built a custom server-side script-engine so that we could essential call C functions on the server right from our java scripts or html. I think that it is more important that our "web" guys understand how to use this engine opposed to being co-owner's of each others web page applications.

Answer 11

I think you take individual ownership of code at the time you write it and then turn it over to the team. This way everyone takes responsibility and contributes. Everyone should want to fix a coding failure they created. Along with a code review this creates higher standards. Nobody wants the job of cleaning up after others.

Think more responsibility and less ownership. After all, whoever is writing the checks is the real owner anyway.

Answer 12

Jim, I'm with you on that one 100%. I'm in the midst of exactly the same battle in my place of work -- which is why I stumbled across your question.

The way I see it is: "when everybody owns it, nobody owns it".

To me, there is no single more important factor to code quality than ownership and responsibility.

Example from real life illustrate this well. which would you take care better: your private lawn or the community's park? Pretty obvious.

That does not, by the way, necessarily has to be traded off for "team flexibility". It merely means that when a person owns something he OWNS it -- and if only for the day.

Answer 13

To me it depends on the dynamics of your team.

For example, if you have a team which isn't unified by standards, peer review, methodical testing, or if you have a team where the competence levels vary wildly among the members, it might be good to seek a stronger notion of code ownership with a more black-box modular mindset.

Lacking this, for example, your carefully-designed interface conforming to SOLID principles might quickly be ruined by someone who doesn't even know "SOLID" means and wants to add new eclectic functions all the time to the interface for "convenience", e.g. This is, by far, the worst.

You might also deal with sloppy co-workers whose idea of fixing a bug is fixing the symptom without understanding the root problem (ex: trying to respond to a crash report by simply putting workarounds in the code only to hide the bug and transfer the deadly side effects to someone else). In that case, it's not quite as bad as interface design sabotage and you can protect your intentions with carefully-constructed unit tests.

The ideal solution is to tighten up your team though to a point where this notion of authorship and ownership no longer become so important. Peer reviewing isn't just about improving code quality, it's also about improving teamwork. Standards aren't just about consistency, they improve teamwork.

Yet there are scenarios where peer review and actually having everyone conform to a standard is just hopeless and will bring a lot of hopelessly-inexperienced critics into the mix. I'd say a lot of whether code ownership or team ownership takes a stronger priority will be based on your team's ability to actually perform an effective peer review and actually leave everyone coming out like they benefited from it (both in terms of the review itself, and becoming closer together in mindset and standards as a result). In large, loose, and/or disparate teams, this might seem hopeless. If your team can function like a "squad" where you can barely even tell who wrote what, then sole ownership will start to seem like a silly notion.

In these kinds of far-from-ideal scenarios, this notion of code ownership may actually help. It's trying to make good of a worst-case scenario, but it can help if teamwork is generally hopeless to put a fence around an author's code. In that case, it's diminishing teamwork but that can be better if "teamwork" only leads to toe-stepping.