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.
