One of the commonly touted programming practices of several agile methods is something called collective code ownership , where anyone on the team can make any authorized functional change or design quality improvement (e.g., a "refactoring") to any file within the scope of their task. The Agile method known as Feature-Driven Development (FDD), featured in another article this month, is one of the few agile methods that uses the more restrictive model of individual code ownership to restrict changes to a class/module to be made by its assigned "owner."
The subject of individual -vs- collective code ownership is often the bane of many heated discussions about code change authorization/access and concurrent -vs- serial development (e.g., copy-modify-merge versus lock-modify-unlock ). Opponents of collective ownership often claim that it results in "no ownership" of the code, and that individual code ownership is better for managing attempts at concurrent changes. Oppenents of individual ownership often counter by saying individual ownership inhibits refactoring and goes against the team ethic of XP and other Agile methods.
The problem with both of these is that they are each extreme positions. Individual Code Ownership, in its purest 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 exclude allowing others to to make updates, we 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, we 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 right balance?
We think there is a successful middle ground, one that is sometimes referred to as 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 committing 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