Balancing Individual versus Collective Code Ownership

[article]
Summary:
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. 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.

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)

About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at steve@berczuk.com or visit berczuk.com and follow his blog at blog.berczuk.com.

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at Techwell.com,  and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

About the author

Robert Cowham's picture Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!