Thoughtful Response Collective Code Ownership

Thrashing can occur by conflicting refactoring efforts. People can get upset with the changes.

Yes, of course there are times when people have different ideas with how a particular part of the system is supposed to work. Life would be much simpler if everyone agreed, but then we wouldn't need any methodologies. But I haven't encountered anything nearly approaching a thrash state where two pairs are in some kind of "DuelingBanjos?" scenario (sorry, another AmericanCulturalAssumption?) trying to one-up each other. A couple things are on your side to prevent this. First and foremost are the UnitTests. If the changes somebody made to your original design breaks one of your tests, it is their responsibility to either make their code work or abandon it and leave the original code in place. If they put in their code and all the tests run, then great. If it causes problems for something that you have written, well then you should put a unit test in for that case. If its just a matter of one preference over another, talk to each other! You don't have time for pissing contests, so get the two pairs together and quickly hammer out an agreement. Remember that one of the tenets of XP is team communication. Now there are (at least) 4 people who understand the design tradeoffs and can communicate that with other pairs when needed.

Second is something that CollectiveCodeOwnership actually helps foster and that's EgolessProgramming. That is, when somebody changes your code to improve the system you learn from it and appreciate it, not think that your idea was somehow bad or wrong. You understand that when you wrote it you did it the best way you could for a particular story. As new stories come along, more is learned and the system is adapted accordingly.

Without a concept of code ownership, we foresee less motivation for pride in one's work. (Perhaps a complete loss of pride.)

From my experience, it's just the opposite. Everyone on the team now has a vested interest in making the whole system something they can be proud of, not just a pocket of their own making. Don't confuse collective ownership with no ownership. Collective ownership allows you the freedom to improve anything that you see could be done better.

When we did the VcapsProject, we actually found everybody's pride and enthusiasm in the system go up dramatically. There weren't anymore comments like "I tried to do it right but this other crap that some Jangmeister (see JangIt) wrote just kept getting in the way, so I had to compromise". What you find is that when you need to add something you can add it the right way because the system is always in a well designed state (RefactorMercilessly, DoTheSimplestThingThatCouldPossiblyWork) and your pride in what you added is increased because you didn't have to compromise your design.

-- TomKubit

One other point to make, and I tried to illustrate it above, is that without some supporting practices CollectiveCodeOwnership might be difficult, at best. But having these practices in place actually makes collective ownership a natural (possibly necessary) addition to the XP practices. -- TK

One of the important supporting practices is a CodingStandard that the group agrees to (and all newcomers to the group have to either accept or go somewhere else). You can't spend time reformatting code or having difficulty reading it -- you need to be able to look at a piece of code and say "hmm, I wonder who wrote that... was it me?" instead of thinking, "Oh, crap, I better fix what's-his-name's indenting so I can read this, THEN I can refactor it."

Don't confuse collective ownership with no ownership.

This is an excellent point. When you practice collective code ownership, your pride is a little different, and is based on different things, but it's no less real. It can be a lot better. See comments on choral singing in AnalogiesFromMusic.