Individual vs Collective Code Ownership: Stewardship to the Rescue

I heard another argument today claiming that collective code ownership often results in "no ownership" of the code, and that individual code ownership is better for managing attempts at concurrent changes.

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
  

At the same time, I have seen cases where "Collective Code Ownership" degrades into "no ownership" when there is no collective sense of team ownership or accountability.

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)

This can be accomplished by pairing with the code-steward, or simply by seeking them out as an FDD programmer would a Chief programmer/architect. The code-steward is like the "editor-in-chief" of the module or class. They do not make all the changes, but their knowledge and expertise is still applied throughout. The benefits are:

• 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)

I guess the bottom-line for me is that collaborative ownership and authorship is still essential, and code ownership isnt supposed to be about controlling concurrent access (and is very suboptimal as a concurrency-strategy, even though some merge-a-phobic shops will swear by it). If we take "ownership" to either extreme - the result is impractical and imbalanced.