Then I heard someone try to counter by saying individual ownership inhibits refactoring and goes against the team ethic of XP and other Agile methods.
The problem I have with both of these is that they are each extreme positions. I know from experience there is a successful middle ground, one that is sometimes referred to as code stewardship.
Individual Code Ownership, in its purist form, means exclusive access control: no one but the "owner" is allowed to edit the particular module or class. When code ownership is interpreted so rigidly as to exlude allowing others to to make updates, I have definitely seen it lead to the following problems on a regularly recurring basis:
- Causes lots of wait-time and productivity-blocks
- Used as a parallel-development block to avoid merging concurrent changes
- Holds changes/code "too close to the vest" and leads to defensiveness and/or local optimization at the expense of the "whole" team/system
- Increasing the project team's "truck factor" by limiting the number of people with intimate knowledge of that module/class within the overall system
So what is the balance? I think it is Code Stewardship, where the code-steward is both guardian and mentor for the body of knowledge embodied by the module/class. The Code Steward's job is not to safeguard against concurrent-access, but to instead safeguard the integrity+consistency of that code (both conceptually and structurally) and to widely disseminate knowledge and expertise about it to others.
- When a portion of a module or class needs to change, the task-owner needs the agreement of the code-steward.
- The task-owner explains what they are trying to accomplish, the code-steward helps them arrive at the best way to accomplish it, and provides any insights about other activities that might be related to it.
- The task-owner makes their changes, seeking advice/counsel from the code-steward if needed (possibly thru pairing or dialogue or other means)
- Before commiting changes to the codebase, the code-steward is involved in review or desk-checking (and possible coordination of concurrent activities)
- Concurrent changes can still be made and wait-times avoided while still permitting notifications and coordination.
- Knowledge is still disseminated (rather than hoarded) and spread-around the team
- Collective ownership and its practices, such as refactoring, are still enabled
- Pair programming can still be done, where pairing assignments can be based in part on who the "steward" is for a piece of code. (At some point stewards can even hand-off-the baton to another)