Many in the Agile community have been practicing Collective Code Ownership for a few years now and we've had time to find some of it faults.
According to Martin Fowler, author and Chief Scientist at ThoughtWorks, Collective Code Ownership (CCO) abandons any notion of individual ownership of code. Instead the code is owned by the entire team and anyone can make changes to it. The commonly cited benefits include increasing the "truck factor", load balancing (minimizing bottlenecks) and exposing code for everyone to see. In addition Ward Cunningham, inventor of the Wiki and CTO for AboutUs, suggests that CCO increases pride in your development work because its always on display for the entire team to see instead of being hidden behind an impenetrable API.
For all the benefits Larry O'Brien, former editor of Software Development and Computer Language, says that CCO has a significant flaw: it hides Bad Programmers from management. Larry has two key points:
- "Bad programmers are not good programmers who are slow. They are actively counter-productive to the team."
- CCO hides bad programmers since the good ones spot and refactor their messes, management doesn't know that the bad programmers are a drag on the team.
Brad Appleton, principal software engineer for Motorola Global Telecom Solutions Sector, has seen many cases where CCO degrades into "no ownership" and no accountability. Instead he proposes Code Stewardship (Martin Fowler calls this Weak Code Ownership), where:
the code-steward is both guardian and mentor for the body of knowledge embodied by the module/class. The Code Steward's job is not to safeguard against concurrent-access, but to instead safeguard the integrity+consistency of that code (both conceptually and structurally) and to widely disseminate knowledge and expertise about it to others.
So Collective Code Ownership can work well but you have guard against the chaos of "no ownership" (either through discipline or code stewards) and watch out for bad programmers who actively slow the team down.
Community comments
A correction
by Sidu Ponnppa Chonira Kariappa,
Re: A correction
by Mark Levison,
Bad Programmers Can't Hide From the Team
by Michael Nygard,
Need for management code reviews
by Chris Wilkes,
Re: Need for management code reviews
by Mark Levison,
But it's often misused
by Simon Lin,
Re: But it's often misused
by Mark Levison,
Situational Code Ownership
by Brad Appleton,
Re: But it's often misused
by Jeff Santini,
Hiring process
by Emerson Leite,
A correction
by Sidu Ponnppa Chonira Kariappa,
Your message is awaiting moderation. Thank you for participating in the discussion.
'CCO hides bad programmers since the good ones spot and refactor their messes, management doesn't know that the bad programmers are a drag on the team.'
I'm not defending CCO - it has its weaknesses like everything else - but what Mr.O'Brien describes is not one of them. Rather, I would consider this a failure of communication between developers and management. If developers are first class citizens in their organisation, then there is nowhere for bad developers to hide (and I'm saying this from experience).
Re: A correction
by Mark Levison,
Your message is awaiting moderation. Thank you for participating in the discussion.
Sidu - I think that you and I are in agreement. However Larry's point is still valid because of CCO anyone who doesn't have direct contact with the code won't know whats happening.
I had been going to say that means its up to Scrum Masters and Coaches to make management aware of problems.
Bad Programmers Can't Hide From the Team
by Michael Nygard,
Your message is awaiting moderation. Thank you for participating in the discussion.
We have to look at the alternative. Without CCO, bad programmers often hide in their cubes, creating disasters in the dark.
Opening up code from a departed programmer can be a truly horrifying discovery.
With collective ownership, the team as a whole will very quickly discover who's harmful. This also turns out to be a much more reliable judgment than any code metrics yet invented.
If you want to know who the bad ones are, there's a simple process:
1. Win the trust of the developers.
2. Ask them.
Need for management code reviews
by Chris Wilkes,
Your message is awaiting moderation. Thank you for participating in the discussion.
CCO hides bad programmers since the good ones spot and refactor their messes, management doesn't know that the bad programmers are a drag on the team.
Can this be fixed with some sort of tool that dev leads / managers look at to determine who is doing the best work? Sure they can look at SCM logs but try doing that over the course of months with hundreds of checkins
But it's often misused
by Simon Lin,
Your message is awaiting moderation. Thank you for participating in the discussion.
I had a post about CCO(www.simonlin.ca/2007/07/17/collective-code-owne...). Mark actually commented on it.
My point is that it's a good practice. But it's often misused. It sometime results in programmers don't feel responsible for their code and the ones who feel responsible always end up cleaning up the mess. Some time it's not even that their code is bad. It might just not be following the best practices or written in a different coding style. I wouldn't care too much if I did't have to maintain their code and fix the tests they broke. If we all live in a perfect world, I would just go to those guys and point out what's wrong with their code. But in reality, I will be considered not a team player. Face the facts, guys. There are not too many projects with zero political factor. I prefer what we do at my current job: everybody is free to change every piece of code but every module has a number of main contributors (the number is always greater than two).
Re: Need for management code reviews
by Mark Levison,
Your message is awaiting moderation. Thank you for participating in the discussion.
I don't know that its needs to be fixed. It just means that we have to remember to communicate. If your Scrum Master talk to your management about problems your team is having. That includes bad programmers. If your management talk to your Scrum Master and ask about problems.
Re: But it's often misused
by Mark Levison,
Your message is awaiting moderation. Thank you for participating in the discussion.
Simon effectively what you have is Code Stewards or Weak Code Ownership. As Martin Fowler points out this model can work too.
In my mind for CCO to work you need to do pair programming. If your not then its hard for every team member to remember to maintain the disclipine and keep the code clean.
Re: But it's often misused
by Jeff Santini,
Your message is awaiting moderation. Thank you for participating in the discussion.
The ownership of your code sounds collective to me
Hiring process
by Emerson Leite,
Your message is awaiting moderation. Thank you for participating in the discussion.
Mike, Your hiring process can avoid you from this. You can have an interview with team members trying to know the correct level of the candidate. Indeed, it's not safe, but it can help.
Situational Code Ownership
by Brad Appleton,
Your message is awaiting moderation. Thank you for participating in the discussion.
The linked-to blog-entry of mine describing code-stewardship is a bit old and has since been more thoroughly described in an April 2006 paper in the CM Journal entitled Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership. The main point is that individual versus collective code ownership is really a spectrum, and what is called for is situationally-aware adaptation such as that exemplified in situational leadership.
There is no single "right" answer - we must consider the dynamics of the team and the trust+skill levels of the individuals. And even when you find an appropriate mix, that is just the starting point on a journey to higher competency, higher-trust and higher productivity.
Stewardship is one of the better ways to catapult yourself along on that journey if you cant start right at full collective ownership, but have at least enough skill & trust that you needn't resort to strict individual ownership.