What is code ownership?
Code ownership is a software industry term for assigning the responsibility of a codebase (or a part of it) to an individual person or distributed across a larger group. The scope of ownership may be limited to the source code only, meaning the owner makes all the architectural and design decisions, implements changes, and maintains bugs and vulnerabilities.
Ownership can also be much broader, including responsibility over all of the systems involved in the execution and delivery of the code in pre-production and production environments.
This is part of a series of articles about code collaboration.
Code ownership encompasses a variety of work, such as:
- On-call and incident resolution duties
- Security vulnerability remediation
- Code review every pull request for the relevant code
- Size and performance optimizations
- Architectural opportunities and decisions
- Integration opportunities, decisions, and maintenance
- Writing and maintaining technical documentation for internal and external consumers
Individual code ownership vs. collective code ownership
The two types of code ownership are individual code ownership and collective code ownership. How it’s understood, decided upon, and implemented depends on multiple factors:
- Code authorship (i.e., who wrote it)
- Available subject matter expertise
- Organizational structure (think “lines of business” or “functional teams”)
- Organizational size
- Criticality and risks associated with the software component(s)
- Executive job titles
Individual code ownership
Individual code ownership means one person (or a small team) has full responsibility for the codebase. More importantly, it means that no one except the owners can make changes to any part of the code. In smaller organizations or where technical expertise is limited, it may be more likely that code is owned by an individual. In larger organizations with high-stakes software initiatives, it may be more likely that code is owned by a team. In either case, anything that needs to happen with the owned codebase needs to be approved, designed, and implemented by the owner.
Collective code ownership
Collective code ownership means all members of a development organization have equal responsibility for the codebase. This means that any team member can make changes to any part of the code, regardless of who originally wrote it. The goal of collective code ownership is to promote collaboration and shared responsibility among team members and to make it easier for the team to respond to changes and adapt to new requirements quickly. One potential downside of this approach is that it can lead to confusion and lack of accountability if team members are not careful to communicate and coordinate their changes.
Code ownership challenges
There’s debate around the merit of code ownership and whether it’s a net positive for a software organization. Some argue that code ownership is problematic, creates a culture of blaming, and lowers code quality. Others say that it allows an owner to maintain deep expertise, keep the codebase clean, and ensure quality is high. However, since it is very hard to measure, it’s unclear whether these benefits ever become a reality.
Code ownership creates silos of knowledge and expertise
Code ownership can lead to silos of knowledge and expertise within a development team. When key information is limited to a small number of people, teams have difficulty collaborating and moving projects forward quickly. Code changes are more difficult to implement, test, and validate. Problems cascade from there.
- Developers need to coordinate and collaborate with other developers, especially on large projects with many dependencies. When they are dealing with ownership over different parts of the codebase, there may be confusion as to who owns what code and how to get it updated to meet a project’s requirements.
- Integrations and compatibility challenges also arise in environments with siloed knowledge and expertise. Conflicts over design and implementation decisions take longer when the expert members are unavailable or are behind on their work.
- Developers may need to navigate complex hierarchies and approval processes in order to make changes to code that is owned by others. Sometimes these challenges are only solvable by the people in the siloes.
- “The bus factor – what if so-and-so gets hit by a bus?” There’s significant business risk of one code owner having a life event that removes them from the workforce, even just for a short time, or if they leave the company. Businesses may have trouble discovering or transferring that person’s knowledge in a timely way, if at all.
Code ownership inhibits knowledge sharing
Code ownership environments can create cultures where developers hesitate to share knowledge. Doing so could potentially expose them to competition or even threats to their job security. For example, there may be performance or bonus incentives for one person or team to maintain exclusive expertise over some code. Sharing that information can commoditize what currently has high value.
The complexity of the codebase and the hierarchical structure of ownership can also make it difficult for developers to access the information they need in order to perform their jobs effectively. These situations hinder the overall productivity and success of the development team. Complexity and hierarchy are likely to increase with the overall size of a codebase. Couple that with the siloed knowledge problem, and it’s likely that a team or project can get stuck.
Code ownership makes code harder to change
Changes to the owned codebases can be more difficult for several reasons. The code may be owned by multiple developers, each of whom has their own perspective and priorities. The difficulty of coordinating changes and ensuring consistent and efficient implementation will only increase.
Additionally, the hierarchical structure of code ownership can create bottlenecks and approval processes that slow down the development process and make it more difficult to make changes quickly. Furthermore, the complexity of the codebase and the potential for conflicts over design and implementation decisions can also make it harder to make changes.
Finally, code ownership can make technical debt issues opaque to the broader organization. If the experts are managing tech debt, they may have no incentive to broadcast their debt. The costs of this tech debt may not be felt until it’s too late, as it’s not transparently shared across the codebase.
Code ownership solutions
The challenges of code ownership can be deeply intertwined with challenges in an organization’s culture. While some might argue that the only way to solve these problems is to eliminate code ownership altogether, for large organizations, this may not even be realistic.
There are a few solutions to the challenges of code ownership:
- Adopt a more decentralized and collaborative model of development, where ownership is shared among all members of the team.
- Implement agile development practices and use tools to streamline the development process and make it easier to manage changes to the codebase.
- Conduct regular code reviews to share knowledge and best practices to improve the overall quality and maintainability of the code.
Documentation and code ownership
The fourth solution for code ownership is the introduction of documentation.
In contrast, with collective code ownership, all team members are responsible for maintaining the documentation, which can help to ensure that it is more complete and accurate. Additionally, collective code ownership can make it easier for team members to share knowledge and expertise, improving the quality of the documentation overall.
Using Swimm to avoid the risks in code ownership
The risks of individual code ownership are clear:
- Too much responsibility rests on the shoulders of a small number of people
- Damage from technical debt isn’t always felt immediately but usually accumulates over time.
- Information and knowledge are easily silo’d
- Quality and productivity can suffer
Swimm’s technical documentation platform helps engineering teams create and maintain high-quality code-coupled documentation that’s always up to date and easy to find the moment you need it. With knowledge sharing, documentation is integrated into dev team workflows so that:
- Responsibility is shared across a collective group of people, and there is no organizational panic when an employee with deep tribal knowledge decides to leave a company.
- Information and knowledge are easily requested, created, and maintained.
- Changes to code and doc creation go much faster, easier, and more efficiently.
- Quality, developer velocity, and productivity improve significantly.
- A culture of documentation is created throughout the entire development process, whether code is directly involved or not.
You can reap the benefits of a code-coupled, Continuous Documentation platform like Swimm today. Sign up for a free account and see first-hand how collective documentation ownership works.
