Agile Glossary

Collective Ownership

What is Collective Ownership?

Teams typically adopt conventions governing who is allowed to modify some source code that was originally written by another, often referred to as “ownership”. These conventions can be written and explicit, merely oral, or entirely implicit. Many different modes exist; commonly only one developer “owns” each code file. Collective code ownership, as the name suggests, is the explicit convention that “every” team member is not only allowed, but in fact has a positive duty, to make changes to “any” code file as necessary: either to complete a development task, to repair a defect, or even to improve the code’s overall structure.

Expected Benefits

A collective code ownership policy:

  • reduces the risk that the absence (or unavailability) of any one developer will stall or slow work
  • increases the chance that the overall design results from sound technical decisions, rather than from social structure, as in “Conway’s Law”
  • is a favorable factor in the diffusion of technical knowledge
  • encourages each developer to feel responsible for the quality of the whole

Common Pitfalls

Tacit or implicit rules may exist that contradict a collective ownership policy adopted by the team. For example, a developer becomes ill-tempered whenever files from a particular component are modified, so that the team starts to treat them as “de facto” under his or her exclusive ownership. Be sure to check that the policy is consistent with actual behavior.

Potential Costs

While the idea of collective ownership is aligned with other principles of shared responsibility in Agile (such as shared responsibility, between customer and development team, for project outcomes), it has its detractors. Arguments against are also plausible and bear being careful about:

  • in the limit, having everyone responsible for quality can be a situation indistinguishable from having no one responsible for the quality
  • the lack of social enforcement of boundaries around code components can lead (by “Conway’s Law”) to a lack of well-defined interfaces, however well-defined interfaces are a key to effective design

Origins

  • 1968: “Conway’s Law” is coined and summarized as follows: “Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.” It has long had the status of folklore rather than of well-supported scientific results, though recent studies have lent it some academic support. (The social aspects of software development remained largely ignored by academic software engineering until the mid-90s.)
  • 1995: Coplien names the “Code Ownership” pattern in Pattern Languages of Program Design, in an early version of his “Organizational Patterns”, a work influential in the later development of Agile discourse. However, he endorses exclusive individual code ownership and cautions against collective ownership which he equates to no ownership at all. Coplien admits that objections against individual ownership exist, but argues that other of his patterns mitigate those problems.
  • 1998: the earliest writings on Extreme Programming recommend “Collective Code Ownership” as an official practice. The “extremos” argue, much as Coplien does in the opposite direction, that other Extreme Programming practices mitigate the problems cited against collective ownership: uniform code conventions and extensive tests.
  • 1998: The earliest article about Extreme Programming, “Chrysler goes to Extremes,” describes several XP practices such as self-chosen tasks, test first, three-week iterations, collective code ownership, and pair programming.
Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Thank you to our Annual Partners​

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs.

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.
A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.
An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.

Help us keep the definitions updated

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now