Code Ownership

Pride of ownership is evident in the well-kept grounds surrounding this bungalow.

Paul Bramble relates, "Code Ownership: Boy, can you say that again. I have been in a place without code ownership. We had token code ownership in that we were generally held responsible for some products — and hence the code. But others could and would change the code to add new features provided that you weren't updating the code during a release cycle. Part of that was nice, as I would be busy doing other things, and didn't need the aggravation of figuring out the details necessary to implement their changes (which could be complex). But this positive effect was far less than the havoc these changes could wreak. While my general framework was only adequate (it could have been better), it became rather disjoint with severalencapsulation and abstraction problems once other developers finished changing things — beyond repair, short of a majorrefactoring effort involving several people."

...a project is underway, and mechanisms are in place to document and guide the software architect, and to support coding and unit development activities. The project is too large for one person to comprehend. No single developer can keep up with the changes being made across the system. 

✥ ✥ ✥

Something that's everybody's responsibility is no one's responsibility.

You want parallelism between developers, so multiple people can be coding concurrently. 

Most design knowledge lives in the code. Navigating unfamiliar code to explore design issues takes time. Beyond that, changing unfamiliar code is dangerous; one does not know what the impact of the changes are. 

Provisional changes never work. 

Not everyone can know everything all the time. Even the architect does not know the code well enough to be proficient in all corners of the project (although an architect should understand some coding issues through ArchitectAlsoImplements.) 

Therefore: 

Each code module in the system is owned by a single Developer. Except in exceptional and explicit circumstances, code may be modified only by its owner.** Anyone else wanting changes must approach the owner and get approval. 

Note that ownership implies responsibility for the quality and architectural integrity of the module. This encourages the owner to gain a deep understanding of the module. For an owner new to the module, this means learning the code in depth, usually quickly. Paul Taylor, in his pattern ArrangingTheFurniture, suggests that new owners can gain familiarity and confidence by starting with making cosmetic changes to the code [BibRef-Taylor1999]. (As authors of this book, we noticed the same phenomenon working with this manuscript!) 

How large should a project be to use CodeOwnership? Gerhard Ackermann points out that it doesn't matter: code ownership is a principle of honoring another person's work. We have seen benefits in projects as small as two persons. In such cases, ownership may not be formally conferred, but each person knows who owns what, and consults with the other before changing the code (see also DevelopingInPairs). 

This pattern is very similar to OwnerPerDeliverable. There is, however, a subtle but significant difference. Ownership of deliverables is for the duration of release; its purpose is for accountability in project management. Ownership of code modules, on the other hand, is for long term; ideally the duration of the software. Its goal is to maintain quality and architectural integrity, and to improve speed by reducing discovery costs. This can be helped by the related pattern, DeployAlongTheGrain. 

Arguments against code ownership have been many, but empirical trends uphold its value. Typical concerns include the tendency toward tunnel vision, the implied risk of having only a single individual who understands a given piece of code in-depth, and breakdown of global knowledge. Other patterns temper these problems: 

The pattern StandUpMeeting helps keep Designers and Architects from developing tunnel vision from strict application of this pattern. 

CodeOwnership can lead to bottlenecks, as all changes to a module must funnel through the owner. Furthermore, CodeOwnership can tend to focus critical information in individuals, violating ModerateTruckNumber. Both these can be counteracted by DevelopingInPairs, as well as practices such as design reviews and code inspections. In addition, one can implement CodeOwnership with some flexibility to allow exceptions if needed to resolve bottlenecks (with approval by the owner after the fact.) Gerard Meszaros also notes that the owner may be an single person or a group, with a designated "group head". This is especially helpful in large projects. (Note that ownership by a group should not be construed to be the same as "Collective Ownership", as advocated by some [BibRef-Beck1999]. Ownership by everybody is ownership by nobody.) 

Empirical support for this pattern is strong, although the most striking examples are the problems encountered when there is no CodeOwnership. 

Neil Harrison describes living a "nightmare" with a code module that nobody owned. Because everybody could -- and did -- refactor the code at will, the architecture changed constantly. Keeping up with changes that others made became a significant chore. Ironically, the project had a policy of code ownership, but nobody had taken on ownership of this module. "At length," he notes, "we volunteered to take ownership of the module, even though we were not part of the project it belonged to." At the time of this writing, the offer is being considered. 

Lack of code ownership is a major contributor to discovery effort in large-scale software development today. Note that this goes hand-in-hand with architecture: to have ownership, there must be interfaces. This is a form of Conway's-law-in-the-small (see also ArchitectAlsoImplements). 

✥ ✥ ✥

The architecture and organization will better reflect each other (ConwaysLaw). Related patterns include ArchitectAlsoImplements, OrganizationFollowsMarket, and InterruptsUnjamBlocking. 

Tim Born argues that there is a relationship between code ownership and encapsulation, in the sense that C++ protection keeps one person from accessing the implementation of another's abstraction. 

One can tie this concept all the way back to philosophy of law. In L'Esprit des Lois, Rousseau argues that law is property, and the lack of identifiable property leads to anarchy [BibRef-Rousseau1972]. 

It has been argued that code ownership should be applied only to reusable code. Such a constraint would be worthy of consideration if someone comes up with a good distinction between usable code and reusable code.

GerardMeszaros wrote a related pattern called ArtifactOwnership [BibRef-Meszaros1999]. 

People can abuse code ownership to protect their artifacts from inspection by colleagues or to take unilateral control of system level issues whose changes fall into their domain. Temper these problems with CommunityOfTrust and DevelopingInPairs. FeatureAssignment brings a review perspective that cuts across the code partitioning, and that, too, can help avoid blindsidedness on the part of the code owner.