Intro to Collective Code Ownership

Collective code ownership is an important facet of agile development. In short, it means everyone is responsible for the application's code. But there's more to it than that, of course. What does collective code ownership look like in practice? How does it differ from non-collective ownership? What's the origin of the term? What are the benefits and drawbacks of this approach? These—and more—are the questions we'll be answering in this post.

Let's dig in.

Collective Code Ownership 101

As mentioned, let's start with some fundamentals on code ownership, collective and otherwise. Let's begin by explaining the concept of code ownership.

The Meaning of Ownership in the Context of Software Development

The term "code ownership" and the idea that developers own the code they write might sound weird for those who aren't used to them. After all, doesn't your employer own the code you write while working for them?

Well, yes. But that's not what we mean when we say "ownership" in software development. The word "ownership" in our context means something like "responsibility." If Alice is responsible for a given class or module—in other words, she oversees it and manages its evolution—we say that Alice owns that code artifact.

Individual Code Ownership...

It's very common that software development teams and companies will assign code artifacts—classes, modules, or even whole apps—for specific people to oversee. We say that these people "own" the given portions of the codebase they look after. Only they can work on those portions of the codebase. Alternatively, they can let other people contribute to their "domains," accepting and merging their work after inspection.

The scenario we've just described is what we call "individual code ownership." That is, individual developers are responsible for specific portions of the codebase.

At first, that might sound like a great idea. After all, it's like having guardians for each class, module, and so on. They'll protect their code domains against unwanted intrusions, keeping the code pristine and the features working efficiently and free from bugs.

That's what happens...right?

...Isn't Such a Great Idea

As it turns out, individual code ownership doesn't work that well in practice. Despite having its benefits, there are important downsides:

Development efficiency goes down. Strong ownership creates bottlenecks. If Alice has to either review and approve every contribution to the module she owns or do all of the work herself, the development pace will slow down. New changes will have to wait a lot to be merged into the mainline, increasing the risk of merge and logic conflicts. What's worse: the features and bug fixes take longer to reach the end user.
Knowledge silos. Individual ownership often results in knowledge silos. It's harder to share knowledge when a single person is responsible for a portion of the code. The result is that the team becomes too dependent on that person being available. What if they go on vacation or leave the company?
Poor professional development. Individual code ownership often stunts the professional development of the code owners. If that sounds weird or surprising, think about it this way: being responsible for just a single piece of the application means you don't get to work with different areas of it. You're less likely to experiment with new and exciting technologies. And since you're the ultimate "authority" when it comes to that portion of the codebase—you aren't held accountable to anyone—your coding skills are likely to take a dive.

Poor team morale. Individual ownership might lead developers to feel entitled to the portion of the codebase they "own," to the point of feeling jealously toward their coworkers. That can seriously harm team morale.

Collective Code Ownership in the House

Ward Cunningham summarizes the problems of individual ownership as an obstacle for developers to use their knowledge in making the application better:

All the time we find ourselves in situations where people know things about the program, but they can't apply that knowledge to the program. Why? Because the knowledge runs counter to some organizational decision that was made before they had that knowledge. In other words, the program becomes resistant to that collection of knowledge.

The opposite of individual code ownership is—you've guessed it—collective ownership. Collective code ownership means exactly what its name suggests: the whole team owns the whole codebase. As Martin Fowler says, saying that the whole team owns everything is tantamount to saying that there are no owners at all. So, the creators of this approach could've called it something like "no ownership" or "zero-code ownership." However, they picked "collective code ownership" for a reason. And that is to stress the importance of the whole team sharing responsibility for the application's code.

Who came up with the idea of collective ownership? Though it's often described as an agile practice, collective ownership comes from one specific agile methodology, namely extreme programming, of which collective code ownership is one of the rules.

The Benefits of Collective Ownership

The idea of collective code ownership might seem extreme to those not used to it. Isn't it the same as anarchy? Doesn't it put the project at risk of falling into utter chaos?

No, and that couldn't be further from the truth. Collective ownership brings many benefits to the team or organization that adopts it. Here are some of them:

Fewer knowledge silos. Since no person is the sole owner of a given class or module, the knowledge about that area of the application flows across the team as is necessary.
An increased bus factor. In other words, the team doesn't get too dependent on specific individuals.
More efficient development process. With no specific owners, no one becomes a bottleneck, which might contribute to development speed and efficiency.
More efficient code reviews. It's rare for a single developer to know more than the aggregate of all the other engineers in the company. So, generally speaking, having more people review contributions made to a given area of the codebase results in not only faster code reviews but also better ones.
Increased code quality. For the same reasons as the previous item, collective ownership of code can result in greater code quality.

How Do You Get to Collective Code Ownership?

How do you get from individual to collective code ownership? It depends. For instance, if you're talking about a greenfield project, then don't just assign code owners from day one. Instead, encourage a culture of development centered on pull requests and code reviews, in which any person can review contributions from any other developers.

What if yours is a legacy project that already has strong ownership in place? Well, that's a thornier issue. Be aware of phenomena like loss aversion and understand that demoting people who used to "own" portions of the code can be frustrating. Proceed with caution.

It might be a good idea to make the change gradual. Instead of going from individual/strong ownership to collective ownership in one go, you might prefer to do it in two steps, adopting weak code ownership first. Here's what Martin Fowlers says about weak code ownership:

Weak code ownership is similar in that modules are assigned to owners, but different in that developers are allowed to change modules owned by other people. Module owners are expected to take responsibility for the modules they own and keep an eye on changes made by other people. If you want to make a substantial change to someone else's module it's polite to talk it over with the module owner first.

Additionally, this transition phase might also serve another benefit: the gradual transfer of knowledge from the former owners to their coworkers.

Collective Code Ownership: Challenges You Might Face

It's not all a bed of roses when it comes to collective ownership of code. There are some important challenges you might face in your way.

For starters, it's all too common for collective ownership to degrade into no ownership at all. With no accountability, the quality of the code then takes a deep dive. A good countermeasure for this risk is implementing the weak code ownership mentioned above.

Adopting weak code ownership, at least as a transitional step, might also help with another challenge: getting the buy-in from skeptics. Transitioning to weak ownership and demonstrating that the project doesn't fall into chaos—quite the contrary—is a powerful way to convert the unbelievers.

Code Ownership in a Distributed World

A recent challenge that many companies have had to deal with, not only regarding code ownership but in general, is the sudden shift to remote work. For companies and teams that weren't mainly remote—or maybe didn't have remote workers at all—a sudden shift to this different form of work is certainly no easy feat. From onboarding new team members to how to do pair programming remotely, everything is new.

To help those organizations—and even the ones who aren't new to remote work, but have been struggling nonetheless—we have put together a guide. You can check it out here: "Distributed Agile Teams: A 3 Step Guide to Success.".

Thanks for reading, and until the next time.

This post was written by Carlos Schults. Carlos is a consultant and software engineer with experience in desktop, web, and mobile development. Though his primary language is C#, he has experience with a number of languages and platforms. His main interests include automated testing, version control, and code quality.