I was reading about Extreme Programming and I found this rule :
Collective code ownership means that everyone is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code. Pair programming contributes to this practice: by working in different pairs, all the programmers get to see all the parts of the code. A major advantage claimed for collective ownership is that it speeds up the development process, because if an error occurs in the code any programmer may fix it.
By giving every programmer the right to change the code, there is risk of errors being introduced by programmers who think they know what they are doing, but do not foresee certain dependencies. Sufficiently well defined unit tests address this problem: if unforeseen dependencies create errors, then when unit tests are run, they will show failures.
Is it really a good practice? Have you ever used it? To me it sounds weird, the day you need to understand some code who do you call if nobody is the ownership? Can someone who didn't write the code can really make a good change without consulting who wrote it?
Furthermore I think it can introduce some conflicts in the team. Developer generally don't like to have own code be modified by other.
What do you think?
This post has been edited by skyhawk133: 10 January 2009 - 08:08 AM