Collective Code Ownership: Some Thoughts
Collective code ownership is one of the things we practice on projects using extreme programming and Mike Bria’s post on the subject makes me wonder if code ownership exists on more than one level.
Kent Beck’s definition of collective code ownership is that
Anyone can change anything at anytime
Mike also gives an alternative definition which goes beyond that:
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.
Fo me this second definition goes beyond just describing a belief system about code and seems to be heading more towards the benefits we achieve from close collaboration on a code base using techniques such as pair programming.
I’ve worked on several different teams over the last few years and although we’ve practiced collective code ownership on all of them I’ve noticed that only really on the projects where the whole team practiced pair programming all the time did everyone on the team have a good understanding of all areas of the code.
In those teams where we didn’t pair all the time we tended to end up with people becoming specialised in certain areas of the code, leading to them being asked to do the next story in that area, and so on until other people found it difficult to make changes without consulting them.
It’s almost like the benefits of collective code ownership are lost without the belief system of the team actually changing.
We can still change the code if we want to but we don’t have the confidence to do so since we haven’t done any work in that area.
Even if someone does explain the code to the rest of the team afterwards after they have written it, I don’t think it’s the same as living through the process of writing it, seeing the tradeoffs, limitations and the reasons why decisions were made.
From my experience this happens far more frequently when pair programming as we get to work on a lot more areas of the code as well as working with people who can provide insight on other areas of the code that we might not have worked on yet.
The belief of collective code ownership + pair programming is what leads to that second definition, which surely is the ideal on any software development team.