Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
What's "broken window syndrome"? I'm not familiar with the term. –  uman Jan 4 '11 at 23:49
1  
Broken window syndrome: en.wikipedia.org/wiki/Broken_windows_theory –  Pemdas Jan 5 '11 at 1:03
add comment

11 Answers

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.

share|improve this answer
6  
From an OO perspective, both scenarios become: "Team member ain't around no mo'." Isn't "better employment op" just a subclass of "unfortunate accident?" –  Yar Jan 3 '11 at 22:42
4  
@Yar: yes, though I guess you could still ask someone who found "better employment" to come back for more money... no amount of money is going to bring him back from under a bus :-) –  Dean Harding Jan 3 '11 at 23:33
4  
I encourage the devs in my group to ask/pair with the original author that way you get the faster bug fix along with some distribution of knowledge. –  dietbuddha Jan 4 '11 at 7:44
12  
You know, this is one of those things that are so wonderful in theory but that rarely works in practice. It's because of the tragedy of the commons. If everything is everyone's responsibility, then nothing is anyone's responsibility because anything is someone else's responsibility. Psychologists call it "social loafing". You need a balance of individual responsibility and team responsibility. –  Jason Baker Jan 4 '11 at 21:38
3  
@Dan - In the world of fairies and unicorns where nobody ever avoids taking responsibility and everyone is completely impartial about everyone else's performance, that's the way it works. In the real world where people are human and therefore imperfect, this happens all the time. If you aren't seeing it then you're either not looking or you've somehow hired a team of superhuman beings that are immune to human weaknesses. I know of no team good enough to bypass the laws of human nature. Simply put, teams are good at some things and bad at others. –  Jason Baker Jan 4 '11 at 22:08
show 9 more comments

Ultimately, the team owns the code. But for all of the reasons you mentioned, we have 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.

share|improve this answer
5  
+1 For the point regarding better code quality due to a sense of ownership. That certainly does exist. –  Orbling Jan 3 '11 at 23:20
    
+1. I agree. Ownership definitely affects code quality. –  Karthik Sreenivasan Feb 1 '12 at 17:05
    
+1 (+10 if I could): ownership affects code quality, not only because it gives a sense of pride and, with it, a stronger motivation, but also because it helps to manage code complexity, as explained very well in the essay "Holding a Program in One's Head", see paulgraham.com/head.html. –  Giorgio Aug 9 '12 at 23:05
add comment

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...

share|improve this answer
3  
pro teams have backup quarterbacks –  Steven A. Lowe Jan 4 '11 at 1:36
    
@Steven I already said that; but thanks for reiterating..."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." –  Aaron McIver Jan 4 '11 at 4:39
    
NFL teams have three quarterbacks, not cross-trained players. Sports analogies rarely work in I.T. ;-) –  Steven A. Lowe Jan 4 '11 at 5:45
    
@Steven I'm aware on how the NFL works, again I didn't say backups don't exist but rather trying to spread that knowledge across the entire team is pointless. Developers == players. If we want to introduce titles such as quarterback == architect we could but it boils down to a single team attempting to achieve a single goal. Each week 45 players suit up and of those 45 players 6.6% have knowledge on how to operate the quarterback position. Sounds ideal to me; versus the majority of these posts wanting 75% of the team to have knowledge on how to operate the quarterback position. –  Aaron McIver Jan 4 '11 at 14:30
add comment

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
share|improve this answer
add comment

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.

share|improve this answer
    
+1 for "The reason for this being that if it's everyone's responsibility, then it's no one's responsibility." –  Karthik Sreenivasan Feb 1 '12 at 17:11
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.