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?

  • What's "broken window syndrome"? I'm not familiar with the term.
    – uman
    Commented Jan 4, 2011 at 23:49
  • 1
    Broken window syndrome: en.wikipedia.org/wiki/Broken_windows_theory
    – Pemdas
    Commented Jan 5, 2011 at 1:03
  • 1
    "It also concentrates knowledge of specific functionality with one (or two) team members" ... "Nor am I suggesting building knowledge silos". Isn't that a contradiction? To me, concentrating knowledge with one/two members is the definition of a knowledge silo.
    – sleske
    Commented Apr 22, 2015 at 9:17
  • This seems very similar to another question that came along a few years later.
    – Eric King
    Commented Dec 23, 2015 at 17:36

13 Answers 13


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.

  • 7
    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?" Commented Jan 3, 2011 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 :-) Commented Jan 3, 2011 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.
    – snakehiss
    Commented Jan 4, 2011 at 7:44
  • 19
    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. Commented Jan 4, 2011 at 21:38
  • 4
    I'd argue against that @Jason. If it is the case, you need better employees, smaller teams. Peer pressure should be able to keep that in check, as long as the team isn't a bunch of flakes. Team Ownership does not beget lack of individual responsibility. Commented Jan 4, 2011 at 21:47

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.

  • 5
    +1 For the point regarding better code quality due to a sense of ownership. That certainly does exist.
    – Orbling
    Commented Jan 3, 2011 at 23:20
  • +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
    Commented Aug 9, 2012 at 23:05

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

  • 5
    pro teams have backup quarterbacks Commented Jan 4, 2011 at 1:36
  • 1
    @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." Commented Jan 4, 2011 at 4:39
  • NFL teams have three quarterbacks, not cross-trained players. Sports analogies rarely work in I.T. ;-) Commented Jan 4, 2011 at 5:45
  • 3
    @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. Commented Jan 4, 2011 at 14:30

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.

  • +1 for "The reason for this being that if it's everyone's responsibility, then it's no one's responsibility." Commented Feb 1, 2012 at 17:11
  • @KarthikSreenivasan: Exactly, and then some dysfunctional team members will start (1) making random changes to the code "because the whole team owns the code" and (2) not fixing the errors they introduce "because it is the whole team's responsibility to fix them". I think the ideal solution somewhere between individual ownership and team ownership.
    – Giorgio
    Commented Dec 26, 2015 at 8:46

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

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.


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.


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.


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.


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.


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.


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.


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.

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