« Mixed Feelings Over Firefox | Main | Always check your blind spot! »
February 09, 2005
Collective code apathy
Some time back I was waging a lone war against the XP practice "collective code ownership" as it was defined on our project. The standing definition/catch phrase was "no-one owns the code". When I first came across this term, I initially thought it was just a typo but it became clear that this was written exactly as it was intended. Furthermore, try as I might, I was singularly unsuccessful trying to explain why I thought this was entirely the wrong way to express "collective code ownership".
Recently, this issue crept into my mind again and, as things tend to do, distance and time clarified my muddled objections to this phrase... via a potentially weak analogy :-)
Scenario One: A company goes bankrupt. A company that I have no stake in. No shares. Nothing. Result: I care not (unless it's someone like Enron where I might chuckle a little).
Scenario Two: Another company goes to the wall. This time I'm an investor, having held shares in the company for several years. Result: I care. How much I care is probably correlated to the size of the stake I hold, but I still care. Presumably, I'd be aware of the problems long before Chapter 12 was the only option and I'd be trying my utmost to not let things get to that point, fairly certain that the other investors would be similarly involved.
Obviously, Scenario Two is the sort of development environment I'd like to work in - one where everyone has a vested interest in the result of the whole exercise. I want everyone to feel that they have a stake in the codebase, so that any signs of distress are treated with the respect and promptness they deserve.
So however inconsequential the original phrase may have seemed, within it lay a worrying assumption about the values held by the team.
Posted by Andy Marks at February 9, 2005 03:39 PM
Comments
collective code ownership = _everyone_ owns the code.
Ownership confers responsibility. Who is responsible for a piece of shitty code? Well, Jimbo wrote it, it must be him. Bzzt... if everyone owns the code, and you are part of "everyone", then you are responsible. Of course, Jimbo is responsible as well, but that doesn't let you off the hook.
Posted by: Robert Watkins at February 9, 2005 04:51 PM
I had understood "collective code ownership" to mean "everyone owns the code". Dunno where I got that from, though.
Posted by: Liz at February 9, 2005 08:42 PM
In practice it's normally collective code disownership
Posted by: Jon Eaves at February 10, 2005 09:50 AM
Yup, I've definitely seen this pattern. I like to call it "collective code dis-ownership", where upon finding a broken window, the typical response is "it's not my problem".
There are many factors that can create this kind of culture. As you say, care is one factor - people need a reason to care about the success of the company/project. There must be a focus on team (as opposed to individual) results. Supporting practices such as automated testing need to be in place to give developers the confidence to fix things. The organisation needs to be supportive, too, rather than imposing barriers to change. If any of these are missing, it's very easy for collective ownership to gradually devolve into collective dis-ownership.
In cultures like the above (e.g. no tests, no focus on team), I would first try to change the culture. Where this isn't possible, collective code ownership is probably a futile goal, so I might resort to identifying a "caretaker" for each major system component.
Posted by: Mike Williams at February 10, 2005 10:14 AM
Sometimes bosses come to the rescue and shake of the pointy-haired reputation. I had a fellow developer who complained about others editing "his code". My boss looked him in the eye and said with a forceful voice, "No, MY code. It is ALL my code. And I hire all of you to work on it." That fixed the problem in a hurry.
Posted by: B. K. Oxley (binkley) at February 10, 2005 02:06 PM
In the 2nd ed of XP Explained, Beck breaks the XP practices into "primary" and "secondary" practices. The primary ones are those any development shop should be able to adapt, and are fairly safe to try to do so. The secondary ones are the ones that are dangerous to do if the conditions aren't right (but are typically the more powerful ones).
Not suprisingly, collective code ownership is a secondary practice; it requires a mature team with a well-defined sense of responsibility.
Posted by: Robert Watkins at February 15, 2005 11:29 PM
Post a comment
Thanks for signing in, . Now you can comment. (sign out)
(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)