Hmm.... this post advocating Collective Code Ownership as "the most important principle of XP" has a link to my comment on "bad programmers are not good programmers who are slow"
The implication is that either:
- Counter-productive programmers are a myth and a scapegoat at all times, or
- CCO is a cure for counter-productive programmers
If (1), I'll restate that what little evidence we have about programmer productivity points to a productivity distribution that's skewed with a long tail of incompetence.
So, (2) CCO is a cure for low- or counter-productive programmers. I don't see that at all. For one thing, I don't see any mechanism by which CCO improves the talents of the worst programmers. It exposes them to higher-quality code than they write, true, but bad programmers don't learn by example (I'm tempted to say their lack of self-educational initiative is their defining characteristic).
From a managerial perspective, CCO can actually hide poor programming, in that a poor programmer does a "works on my machine" or "works for the default scenario" piece of crud, and a good programmer comes through and refactors the work before the poor programming is exposed. The good programmer is disgusted and frustrated and slowed, but management sees Bob The Poor and Gwen the Great as both finishing one task.
With version control logs, Bob's role in the poor work is not hidden to Gwen either, so it's not the case that the communal nature of CCO tempers her resentment.
I'm 100% for CCO, but I don't see it as having anything to do with incompetent programmers. (Clarification: I'm 100% for CCO, but that doesn't mean it can't 'hide poor programming' as discussed above. Nothing's perfect.)