Are there weaknesses with Collective Code Ownership?

| by Mark Levison Follow 0 Followers on May 06, 2008. Estimated reading time: 1 minute |

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:

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.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

A correction by Sidu Ponnppa Chonira Kariappa

'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

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

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

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

I had a post about CCO( 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

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

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

The ownership of your code sounds collective to me

Hiring process by Emerson Leite

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

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

10 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you