Mi Code-ah, Su Code-ah

In one sentence, what does 'Collective Code Ownership' (CoCO) mean?

In the words of Kent Beck, it means "Anyone can change anything anytime".



Said another way:  There ain't no such thing as 'My code, your code'.  Them there is bad words, mi amigo.

And then, in many more sentences...

How many times have you been routed a defect that came out of your team but you had no idea how to address it because you "didn't code that part"? How many times have you been unable to take on a story because "Jerry's the only one who knows the business logic"? How many times have you been unable to proceed until you got approval from the person who "knows that code"? How many times have you had to leave a story on the shelf because the person who "owns that code" got wolfed for a few days (or "hit by a bus")? I could ask these questions forever but I'll stop there, I expect you get the point.

Thus, as one of the main practices that stems from the value of Collaboration, Collective Code Ownership aims to break those recurring enemies of productivity. It says that, certainly within at least a team, everyone owns all the code. Furthermore, everyone is free to...scratch that, everyone is responsible to be equipped to effectively make updates to absolutely whatever code their story takes them to -- without feeling like an intruder and without having to get "permission" or any non-casual advice from your so-called "expert" or "owner". From a more measurable POV, CoCO states that everyone on the team (developer-wise) must be able to describe the design of anything the team is working on in no more than 5 minutes.

So, why possibly might this not always happen? Well, I see at least a few reasons.

• First, it requires a very high level of collaboration and trust within a team, something that, unfortunately, isn't necessarily present "We've gone Agile! Day 1".
  
• Second, it might not absolutely require it, but a test-covered, well-factored, and expressive code base goes a very, very, very, very, very long way to making this work. Ok, I lied, it is required. And again, this is something that for many new teams is simply not the situation.
  
• Third, in many cases, particularly on bigger enterprise-y projects, it simply takes a good amount of work and an investment in time (which, of course, is money) to make this happen. Alas, to much dismay, its an investment that often ends up taking a back seat to "hittin' that next deadline".

And lastly, it takes courage. It takes being comfortable with stepping out of your "comfort zones" (pun intended) every now and again. It requires shifting your self-image from "I'm good at working on this code" to "I'm good at working on code".

Heck, isn't that why you became a programmer in the first place? You didn't start your days banging on the keyboard dreaming of being "the dude who knows the billing system inside & out", or "the keeper of the logging framework", or "the Hibernate guy" did ya? You loved code, programming, creating things, bringing new stuff to life, a real Doc Frankencoder. Tap back into that, set the inner geek free, you'll be happier for it.

And, you're in luck, the benefits do not stop there.

At a team level, having a collective code ownership implies more freedom to have people pick up the most important stories or tasks, independent of what part of the app they may affect. It allows you to focus more people on the next story, to have the team bum-rush it, get it started then completed quickly before moving onto the next most important story, which in the end is a better way to run your iteration than to "multi-thread" many concurrent stories.

Does this mean that your team will religiously have everyone working on everything, everyday?  Course not, even if that did make sense, it ain't physically possible (in this dimension).  But it does mean that you should switch up pairs periodically (preferably at least daily), and share a story's tasks amongst your pairs. Have pairs face each other and be in earshot, rather than nestled off in their own cubbies and corners.  Have team design pow-wows around the whiteboard and code reviews around the projector every couple days. Use your wall-space to document decisions and debate working designs.  Collectively own the problems, collectively own the decisions, collectively own the code.

And at an organizational level, Collective Code Ownership allows your teams to grow in a way that keeps up with the way your product matures.  Many applications will start their life having intense development needs in each of its various components, and logically teams will form around these components.  This may work initially (or it may not), but it comes with a natural tendency for silos of knowledge to form around the components, which will become problematic and counter-productive as the product matures and the user's needs shift away from "component-based enhancements" and more towards "application workflows" that span multiple components.

So, yes that's right, I'm saying that Collective Code Ownership in fact goes beyond "your team"; it applies as well to "your organization".   Do the same rules apply as within the team?  "Everyone codes everything everyday", "pair with everyone", "describe the design in 5 minutes", etc?  No, it doesn't necessarily mean that.  But it does mean that you should initiate mechanisms for people to periodically get a glimpse into what other teams are working on, both functionally and technically.  It does mean that you might need to let your teams re-assemble now and again to spread knowledge and prevent yicky silos.

And finally, most importantly and most simply, whether "your team" or not, Collective Code Ownership, more than anything, is a state-of-mind:  if you need to change some code, then damn it,  its yours to change - and that's all good!

* Check out also what we IXP'ers say officially about "Collective Ownership".