Xp Team Vs Individual Code Ownership
Dr. Leslie. N. Smith asked the question:
I have a question that I have not seen addressed anywhere. Specifically, the XP Website at http://www.extremeprogramming.org/ recommends collective code ownership. At the address http://www.extremeprogramming.org/rules/collective.html it says:
- Collective Code Ownership encourages everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, or refactor. No one person becomes a bottle neck for changes.
However, there is also a Website and mailing list for organizational patterns at http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns. If you go there, you will see a book in progress describing various patterns for the Software Development Organization. In regards to code ownership, at the address http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?CodeOwnership it says:
- Something that's everybody's responsibility is no one's responsibility.
- You want parallelism between developers, so multiple people can be coding concurrently.
- Most design knowledge lives in the code. Navigating unfamiliar code to explore design issues takes time. Beyond that, changing unfamiliar code is dangerous; one does not know what the impact of the changes are.
- Provisional changes never work.
- Not everyone can know everything all the time. Even the architect does not know the code well enough to be proficient in all corners of the project (although an architect should understand some coding issues through ArchitectAlsoImplements.)
- Therefore:
- Each code module in the system is owned by a single Developer. Except in exceptional and explicit circumstances, code may be modified only by its owner. Anyone else wanting changes must approach the owner and get approval.
This clearly indicates that the better practice is individual code ownership. Can someone please resolve this difference for me?
The difference is that the IndividualCodeOwnership pattern is assuming the absence of a bunch of XP practices: PairProgramming, ExtremeUnitTesting / TestFirstProgramming, AcceptanceTesting, CodingStandard, MercilessRefactoring, etc...
PairProgramming means that two pairs of eyes have seen each piece of code in a system, so no code is "unfamiliar". It also means that anyone changing a piece of code is not doing it alone, and can opt to pair with one of the persons who wrote it originally.
The UnitTesting practice requires that all unit tests pass before code is checked into the main stream of the group's source-code-control.
TestFirstProgramming means that tests are written before code is created or changed, and no code should be written or changed unless there is a failing test.
AcceptanceTests are run frequently. If someone broke key portions of code, the acceptance tests will start failing, signalling that something is wrong.
The CodingStandard is designed to make sure that all code in the project looks the same, no matter what pair wrote it. This improves the ease of comprehension.
MercilessRefactoring (see http://www.refactoring.com) is all about improving the design of existing code, reducing code duplication, putting in place good names, simple design, etc... IndividualCodeOwnership gets in the way of this, particularly when removing code-duplication requires changing code belonging to several different individuals.
There are several anti-patterns associated with Individual Code Ownership:
- GateKeeperDelay: the team needs some code changed now, but the owner is not around (or willing) to do it. XP is all about developing quickly (but with discipline and high quality), so gate-keeper-delays can not be tolerated.
- EgoDrivenProgramming: the owner refuses to accept other's changes to their code, not for valid technical reasons, but because accepting those changes would be an admission of "being wrong".
- DefensiveObfuscation: the owner is not really up to the task of writing the code, and is afraid of admitting it. The owner writes a big mess of code that no one understands, and which barely works, and tries to avoid modifying it, or letting anyone else modify it.
I have seen all of these Individual Code Ownership anti-patterns in real life. XP defeats the second and third anti-patterns by pair programming - a person in a pair is much less likely to get their ego involved in their code, and the pair partner is there to help when a task is beyond their ken.
-- KeithRay
It is very difficult to understand how this could work if you have not tried it before. I have worked with managers and developers who have found benefit in all the other XP practices and still were not able to imagine this one could work.
The assumption is that if "everyone owns the code than no one owns the code." Clearly in this case you have not achieved the desired goal. The latter is much easier to achieve than the former. In other words, do not accept no one owning the code as a substitute for everyone owning the code. It really is not the same thing.
-- DonWells
Individual ownership and group ownership aren't the only choices. Rather, they're on opposite ends of a continuum that includes other choices. One middle-ground (though non-XP) choice is CodeStewardship. -- DaveSmith
There is a question strongly related to Code Ownership that occurs to me.
In the CodeStewardship site RonJeffries said
- Actually in XP we discourage people gravitating. We recommend switching people around so that you don't get the ego involvement and you do get cross-training.
At the organization patterns site, they advocate Domain Expertise. For example, see http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?DomainExpertiseInRoles where it says
- Spreading expertise across roles complicates communication patterns. It makes it difficult for a developer or other project member to know who to turn to for answers to domain-specific requirements and design questions.
- Therefore:
- Hire domain experts with proven track records, and staff the project around the expertise embodied in the roles.
It seems to me that individual code ownership leads to Domain Expertise, while Collective Code Ownership "discourages people from gravitating." So, I have a similar question as before: Is it a better practice to have a certain amount of Domain Expertise or to discourage it?
Again, it seems to me that the circumstances (eg. project size) might dictate which is the better choice.
-- Leslie Smith
"Something that's everybody's responsibility is no one's responsibility."
In XP individuals are responsible for adding user stories. Team ownership of the code gives that individual (and his partner) the ability to fully implement the designated functionality. When different individuals "own" sections of code, the implementation of a single function may require the coordination of multiple people, leading to the split responsibility problem. In XP, you are responsible for a function and the ownership of the code is shared. This is in contrast to splitting responsibility for the function and having ownership of sections of code. -- WayneMack
See CollectiveCodeOwnership, SpecializationIsForInsects