Are there weaknesses with Collective Code Ownership?
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.
Sidu Ponnppa Chonira Kariappa
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
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
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
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
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
Re: But it's often misused
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.
Situational Code Ownership
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.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015