{"id":5003141,"date":"2015-12-16T21:37:32","date_gmt":"2015-12-17T05:37:32","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&#038;p=5003141"},"modified":"2024-03-22T10:04:39","modified_gmt":"2024-03-22T17:04:39","slug":"collective-ownership","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/collective-ownership\/","title":{"rendered":"Collective Ownership"},"content":{"rendered":"<div>\n<div>\n<p>Teams typically adopt conventions governing who is allowed to modify some source code that was originally written by another, often referred to as \u201cownership\u201d. These conventions can be written and explicit, merely oral, or entirely implicit. Many\u00a0<a href=\"http:\/\/xp123.com\/xplor\/xp0002e\/index.shtml\" target=\"_blank\" rel=\"noopener noreferrer\">different modes exist<\/a>; commonly only one developer \u201cowns\u201d each code file. Collective code ownership, as the name suggests, is the explicit convention that \u201cevery\u201d team member is not only allowed, but in fact has a positive duty, to make changes to \u201cany\u201d code file as necessary: either to complete a development task, to repair a defect, or even to improve the code\u2019s overall structure.<\/p>\n<\/div>\n<\/div>\n<h2>Expected Benefits<\/h2>\n<div>\n<div>\n<p>A collective code ownership policy:<\/p>\n<ul>\n<li>reduces the risk that the absence (or unavailability) of any one developer will stall or slow work<\/li>\n<li>increases the chance that the overall design results from sound technical decisions, rather than from social structure, as in \u201cConway\u2019s Law\u201d<\/li>\n<li>is a favorable factor in the diffusion of technical knowledge<\/li>\n<li>encourages each developer to feel responsible for the quality of the whole<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<h2>Common Pitfalls<\/h2>\n<div>\n<div>\n<p>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 \u201cde facto\u201d under his or her exclusive ownership. Be sure to check that the policy is consistent with actual behavior.<\/p>\n<\/div>\n<\/div>\n<h2>Potential Costs<\/h2>\n<div>\n<div>\n<p>While the idea of collective ownership is aligned\u00a0with 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:<\/p>\n<ul>\n<li>in the limit, having everyone responsible for quality can be a situation indistinguishable from having no one responsible for the quality<\/li>\n<li>the lack of social enforcement of boundaries around code components can lead (by \u201cConway\u2019s Law\u201d) to a lack of well-defined interfaces, however well-defined interfaces are a key to effective design<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<h2>Origins<\/h2>\n<div>\n<div>\n<ul>\n<li>1968: \u201cConway\u2019s Law\u201d is\u00a0<a href=\"http:\/\/www.melconway.com\/research\/committees.html\" target=\"_blank\" rel=\"noopener noreferrer\">coined<\/a> and summarized as follows: \u201cAny 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\u2019s communication structure.\u201d 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.)<\/li>\n<li>1995: Coplien names the \u201cCode Ownership\u201d pattern in\u00a0<a href=\"http:\/\/amzn.to\/2g9T3cY\" target=\"_blank\" rel=\"noopener noreferrer\">Pattern Languages of Program Design<\/a>, in an early version of his \u201cOrganizational Patterns\u201d, 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.<\/li>\n<li>1998: the earliest writings on<a href=\"https:\/\/agilealliance.org\/glossary\/xp\/\">\u00a0Extreme Programming<\/a>\u00a0recommend \u201cCollective Code Ownership\u201d as an official practice. The \u201cextremos\u201d 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.<\/li>\n<li>1998:\u00a0The earliest article about Extreme Programming, \u201c<a href=\"https:\/\/dokumen.tips\/documents\/case-study-chrysler-goes-to-extremes-xswangresearchpapersserelatedxpdc9810case.html?page=4\" target=\"_blank\" rel=\"noopener noreferrer\">Chrysler goes to Extremes,<\/a>\u201d describes several XP practices such as self-chosen tasks, test first, three-week iterations, collective code ownership, and pair programming.<\/li>\n<\/ul>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Collective code ownership is the explicit convention that every team member can make changes to any code file as necessary: either to complete a development task, to repair a defect, or to improve the code&#8217;s overall structure.<\/p>\n","protected":false},"author":6000331,"featured_media":8067461,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","categories":[906],"tags":[859],"class_list":["post-5003141","aa_glossary","type-aa_glossary","status-publish","has-post-thumbnail","hentry","category-technology","tag-xp"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003141","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/aa_glossary"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/6000331"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=5003141"}],"version-history":[{"count":0,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003141\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media\/8067461"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=5003141"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=5003141"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=5003141"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}