Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
News
Are there weaknesses with Collective Code Ownership?
Posted by Mark Levison on May 06, 2008 01:00 AM
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.
RelatedVendorContent
5 Ways to Ensure Application Performance
Ebook: Scaling Agile with C/ALM
Ensuring Code Quality in Multi-threaded Applications
Related Sponsor
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
A correction
by
Sidu Ponnppa Chonira Kariappa
Posted
May 6, 2008 5:53 AM
Re: A correction
by
Mark Levison
Posted
May 6, 2008 8:27 AM
Bad Programmers Can't Hide From the Team
by
Michael Nygard
Posted
May 6, 2008 1:56 PM
Need for management code reviews
by
Chris Wilkes
Posted
May 6, 2008 10:28 PM
Re: Need for management code reviews
by
Mark Levison
Posted
May 7, 2008 8:41 AM
But it's often misused
by
Simon Lin
Posted
May 7, 2008 1:11 AM
Re: But it's often misused
by
Mark Levison
Posted
May 7, 2008 8:43 AM
Situational Code Ownership
by
Brad Appleton
Posted
May 11, 2008 1:22 AM
Re: But it's often misused
by
Jeff Santini
Posted
May 7, 2008 10:25 AM
Hiring process
by
Emerson Leite
Posted
May 9, 2008 12:04 PM
-
'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).
-
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.
-
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. -
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
-
I had a post about CCO(http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/). 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).
-
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.
-
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.
-
The ownership of your code sounds collective to me
-
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.
-
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.
10 comments
Watch Thread Reply