Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership

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 the "steward" is for a piece of code. (At some point stewards can even hand-off-the baton to another)

The bottom-line is that collaborative ownership and authorship is still essential. Code ownership isn't supposed to be solely about controlling concurrent access (and is very suboptimal as a concurrency-strategy, even though some merge-a-phobic shops will swear by it). Code ownership is also about safeguarding the integrity and consistency of the design and implementation, and also about disseminating knowledge of the owned module/class, as well as knowledge of practices and patterns for its succful "care and feeding." If we take "ownership" to either extreme, and keep it there - the result is impractical and imbalanced.

When Brad presented the notion of Code-Stewardshop on several agile forums, he received a great deal of feedback. Most apparent was that he had utterly failed to successfully convey what it was. Despite repeated statements that stewardship was not about code access, it seems everyone who read it thought the code steward, as described, was basically a "gatekeeper" from whom others must acquire some "write-token" for permission to edit a class/module.

That is not how it works. The code-steward serves as a mentor and trail-guide to the knowledge in the code. Consulting the code-steward is not about getting permission, it is about receiving knowledge and guidance:

• The purpose of the protocol for consulting the code-steward is to ensure two-way communication and learning (and foster collaboration). That communication is a dialogue rather than a mere "token" transaction. It's not a one-way transfer of "control", but a two-way transfer of knowledge!

Perhaps a better way of describing it would be the way Peter Block defines stewardship in his book of the same name (Stewardship: Choosing Service over Self-Interest, see an interesting review at www.gbod.org and another review from www.meansbusiness.com):

• Stewardship is being accountable to the larger team or organization by "operating in service, rather than in control, of those around us."
• "We choose service over self-interest most powerfully when we build the capacity of the next generation to govern themselves"
• Stewardship offers a model of partnership that distributes the power of choice and resources to each individual.
• Stewardship is personal - everyone is responsible for outcomes; mutual trust is the basic building block, and the willingness to risk and be vulnerable is a given.
• Total honesty is critical. End secrecy. Give knowledge away because it is a form of power

When practiced properly, collective code ownership is in fact an ideal form of stewardship (but not the only form). Stewardship may ultimately end-up as collective-ownership if given a sufficient period of time with the same group of people. However, early on we expect stewards to have a more direct role. The form of code-ownership that Feature-Driven Development (FDD) practices may seem fairly strict at first, but is really intended to be the initial stages of code-stewardship in the first two quadrants of the situational leadership model.

We believe the form in which stewardship should manifest itself is situational, depending on the skill and motivation of the team and its members. In Ken Blanchard's model of situational leadership, there are four quadrants of leadership-style, each of which should be used on the corresponding combination of hi-lo motivation and hi-lo skill for a given task:

• Directing (hi directive + lo supportive, for "enthusiastic beginners")
• Supporting (hi directive + hi supportive, for "disillusioned learners")
• Coaching (lo directive + hi supportive, for "reluctant contributors")
• Delegating (lo directive + lo supportive, for "peak performers")

If we apply the concepts and principles of "stewardship" using the appropriate situational leadership-style, the outwardly visible result may appear to transition from individual code ownership, to code guardians/gate-keepers, then code coaches/counsellors, and finally to truly collective ownership.

So it is the presence of stewardship which is the key to succeeding with either individual code ownership or collective code ownership. If stewardship is present, then both can succeed; If it is absent, it's likely that neither will succeed. And the collective and individual "styles" are the extreme ends of the spectrum, with "code counsellors" as the style in between those two extremes.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment