What is Code Ownership?

Reasons for Code Ownership

There are various reasons why companies define Code Ownership. Here is a selection:

• Code owners are often familiar with the code they are responsible for. If there is clarity within the organisation about who is responsible for which code base, this simplifies internal communication and often also the exchange of knowledge among each other.
• If a team takes responsibility for a code base, this often leads to improved cooperation within the team, especially if a culture of togetherness is lived and a common desire and demand for high-quality software exists.
• If a developer or a development team is responsible for the code, the identification with the task and the result increases. Ideally, this also improves the quality of the code, minimises errors and facilitates the maintainability of the code.
• Code Ownership is usually accompanied by an increase in motivation among those involved. This can contribute, for example, to minimising or avoiding technical debt, improving code coverage and code security, or trying out innovative approaches.

Some publications state that Code Ownership also leads to improved documentation of the code – but this may just be wishful thinking.

Types of Code Ownership

There are different types of code ownership¹:

• Strong Code Ownership,
• Weak Code Ownership and
• Collective Code Ownership.

Strong Code Ownership – “strong” stands for “strong” – refers to the division of a code base and the assignment of individual developers to these sections. Each developer is fully responsible for his part, i.e. he is responsible for the maintenance and quality of the code. He acts as a gatekeeper, so developers who want to make changes to code they don’t own must get appropriate permission from the code owner. Of course, he is also the person other developers turn to if there is a problem with his code.

Strong Code Ownership looks organised, but in practice it can also be counterproductive. If the code owner is difficult or impossible to reach due to a heavy workload, holidays or leaving the company, then bottlenecks arise. Step by step, they pile up change requests, which increases the amount of unfinished work and reduces the speed of development. In short: Strong Code Ownership is relatively simple, but quickly reaches its limits.

Weak Code Ownership – “weak” stands for “weak” – has some similarities with Strong Code Ownership. The weak code ownership model also divides up the code base and assigns certain parts of it to developers. The main difference is that other developers are allowed to directly change the code they do not own, rather than taking the owner route.

Even though weak code ownership allows more freedom than the “strong” model, this does not mean that code owners are free of responsibility: Code owners are still responsible for the maintenance and quality of the assigned code, and need to be aware of changes that other developers make. Although code owners do not have to make the changes themselves, they are still needed to review and approve the changes made by other developers.

Often, the weak code ownership model is preferred to the strong code ownership model because it increases contributions to the source code and collaboration between team members, ideally without compromising the quality of the code. It also proves to be more efficient and reduces the workload for code owners; team members no longer need to ask the owner to make the changes, but can do so directly.

This model is useful when working to a larger team that has many other common tasks. However, since the code owner is less committed to the code, a lack of responsibility can also be observed time and again in practice, which is unfortunately accompanied by a loss of quality. In addition, confusion increases when it is not really clear who is responsible for making changes and updating the code. And this can lead to conflicts in cooperation and loss of productivity: many developers are occupied with solving a certain problem that could also have been solved by a single developer.

In short, the weak code responsibility model is a good way to avoid the problems that arise when using a strong code responsibility model. Developers have more freedom to make changes without piling up work for the code owner. However, it also has its drawbacks, so it is important for the team or contributors to be clear about who is responsible for the maintenance and quality of the code.

Collective Code Ownership is very different from the two types mentioned so far. In a collective model – the term comes from Extreme Programming, which describes a confluence of values, principles and practices in software development² – there is no individual ownership. Responsibility and management of the code base is shared among all team members. Team members are allowed to make changes to any part of the code, regardless of who originally wrote it.

The collective model encourages all developers to work together to manage and maintain the quality of the code base. It is also more time efficient and reduces the workload, as all team members can contribute and review the code, as opposed to a single person or a small group of people. In other words, it is easier and faster to make improvements and fix bugs.

But as efficient as this sounds, the collective model also has its drawbacks: In the absence of individual ownership, some developers may not be familiar with some parts of the code base, leading to knowledge gaps and possible misunderstandings. In addition, there is no dedicated code owner available to manage and coordinate the work of multiple team members, leading to difficulties in structure and organisation. Furthermore, this model can prove counterproductive as more meetings are needed to coordinate with other team members.

In short, the collective code ownership model has the potential to improve a team’s efficiency as well as the quality and maintainability of the code base. However, it is essential that everyone involved is up to date and clearly communicates and understands the consequences of individual adjustments.

Tips for applying Code Ownership

Here are some tips on how to apply Code Ownership:

• Code Ownership can be implemented in different ways. The best way depends on the specific needs of the team, the parameters and your organisation or organisational culture. Determine the scope or extent of Code Ownership. Ideally, decide together with all stakeholders whether responsibility will be given to individuals, selected teams or the collective.
• Communicate the process of code ownership to the team. Make sure all team members know their responsibilities and how to track code responsibility.
• Encourage developers to communicate with code owners. This will ensure that code owners are aware of any changes to the code base.
• Document the agreements. And – almost as a matter of course – use version management and conduct code reviews.

Here are some additional tips for implementing Code Ownership:

• If code ownership is new to you, start by taking code ownership of a few important files or modules. This will help you get a feel for how the process works before you expand it.
• The Code Ownership process should be flexible enough to adapt to the changing needs of the team. For example, it may make sense to change the scope of code ownership or the tracking method as the team grows or changes.
• In many organisations, Code Ownership takes time for the concept to take root. Don’t expect to see results immediately. Just keep communicating the process and encouraging developers to follow it.

And last but not least: stay on the ball, because if you manage to live Code Ownership effectively, the quality, correctness and maintainability of your software will increase.

Challenges of Collective Code Ownership

Even if Collective Code Ownership sounds good as a concept for the collaborative development of software, in practice there are some challenges to overcome:

• For example, it happens time and again in larger projects that “only” one developer feels responsible for a subarea and accordingly acts alone. This almost automatically leads to a knowledge silo and possibly to a dependency on the developer.
• The effort required to exchange knowledge inevitably increases. At the same time, the added value per developer can decrease.
• Developers are only human, i.e. they like to work with colleagues they like. Without coordination by a development management, this can lead to the same people always working together, thus creating knowledge islands. Accordingly, it is difficult for “outsiders” to participate.
• If several developers are responsible for the same code, it can be difficult to determine afterwards who did what and for what reasons, or who is responsible for a certain error or problem. A diffusion of responsibility occurs, which easily leads to increased effort (and blame).
• It is also conceivable that shared responsibility leads to individual developers being reluctant to make changes for fear of unintended consequences and negative reactions from others.

Some publications state that without unambiguous responsibilities, it can be difficult to maintain consistent coding standards and practices across the code base. However, whether this is really due to Code Ownership is rather debatable. Opinions also vary as to whether a balance between collective responsibility for the code and individual responsibility for “critical” areas of the code by responsible individuals or smaller groups is useful and desirable.

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.

[1] Here you can find an assessment of Code Ownership types by Martin Fowler, one of the authors and first signatories of the Agile Manifesto.
[2] Extreme Programming now uses the term “shared code” as a method. Felix Stein also propagates Continuous Code Ownership in a four-part series of Gernan-language articles, as it is not enough to deal with the code only in the course of upcoming modifications, as in practice it can often take several years before a certain piece of code is touched.

And here you will find supplementary information from our Smartpedia section:

t2informatik develops and modernises software as a service provider. Click here to learn more.