Sunday, March 27, 2005

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.


Anonymous said...

It's unfortunate that threads on the original Wiki aren't timestamped. The opening posts in the Code Stewardship thread predate public discussion of XP by at least a few months. Things have come a ways in the interim.

Since then, I've seen collective code ownership work well in an XP team. But getting there takes trust. Back then, it was evident that effective pairing was essential to building trust, but I never imagined that trust would also depend on externalized stewardship in the form of unit tests. When we write good unit tests, we invest them with our stewardship. When a team gets beyond adequate unit tests and has Really Good unit tests--good enough to embody a high degree of trust--then new code that passes those tests gains a level of trust automatically. Withholding trust in the presense of a green bar becomes the exception.

Unfortunately, the will to write good tests, either by practicing Test-Driven Design or writing them after the fact, often folds in the face of time and management pressure.

Anonymous said...

code stewardship sounds similar to the role of the committer on an open source project.

Unknown said...

Code ownership is a way to assure convergence of change.

Simultaneous change of the same code must either be executed in a single configuration, or it must be integrated to a single configuration. If not, multiple variants of the same code will exist and need to be maintained and/or evolved. This aspect is particularly addressed by Software Product Lines (

So instead of trying to point to a single person (Code Ownership), a single team of persons (Code Stewardship) or any person, I think we need to focus on a single configuration where changes converge into, and the responsibilities w.r.t. this configuration.