Code Ownership

The following document explains why the need for explicit code ownership practice is important, and how it can directly solve a plethora of common problems facing software engineers in their everyday work. This includes slow code reviews, increasing technical debt, slow development and ambiguity of knowledge source.

Explicitly declaring responsibility for code ownership can have beneficial side effects such as proper technical documentation.

INTRODUCTION

A project which has been running for a few years can become like uncharted territory. This is especially true in startups where turnover is high, knowledge is scattered and there is code nobody knows, nor do they understand what it does after the developer that has already left. This is normally the code that no one wants to touch anymore.

So this is an indicator to treat it as real uncharted territory — where land is not named or owned, people come and claim parts of it, guard it, clean the place, build a house and call it theirs. Any visitors are welcome as long as they follow the house rules.

Territories are transferred, so if an owner looses interest in a land, he can leave it to someone else to take over. But the new person is told about the wolves around, the cracks in the wall, and when it become hot or cold.

Territories could be divided, so you can rent a room in your house, use it as you wish, as long as you follow the landlord’s rules.

GOALS

1. Define clear rules that specify when a pull request can be accepted for merge.
2. Have a specific person responsible for organizing and cleaning code, and reducing technical debt.
3. How to hand over knowledge between developers should be clear and consistent in case of changing ownership or turnovers.
4. Having proper documentation and FAQs for your software is also a side effect.

SPECIFICATIONS

Code with shared ownership is uncharted territory

• Code where no single person understands how it works.
• Code that has multiple unnecessary design patterns, complex structures, and everyone is having trouble justifying why it is the way it is.
• Projects with no clear ownership and everyone is doing the minimum change to fulfill requirements.
• Code that has many pull-request arguments over which is the best way to implement a feature or higher technical decision with no clear authority over the project.
• Projects with no consistent patterns

If the above list seems familiar to you, then you need to mark the uncharted territories in your organization, because an invasion is coming!

Uncharted territories should be claimed

• You should look for code that you want to own, parts you can take care of. Declare it your own property.
• Ownership could be for a whole project or a directory inside a project.
• If another developer is trying to claim the same code, a discussion should take place and an agreement should be met.
• If no agreement can be found, then a vote should be held to decide who should own this code.
• Declaring ownership should be done by creating an “AUTHORS” file inside the owned directory. The file must contain your name and your email.
• You can check if this code is owned or not by traversing the tree to every parent searching for the “AUTHORS” file, if you find it then this part is owned.

An owner can rent part of his property

• A sub-directory of an owned directory could be claimed if agreed upon by all the owners of the parent directories.
• The owned sub-directory is still owned by the parent directory’s owner, so it must follow the same rules.
• One of the owners of the parent directory can remove one of the sub-directory owners (reclaiming his territory).

Owners have responsibilities

You must:

• understand all of your code.
• review all pull requests to your code.
• clean your code, make it better and faster all the time.
• answer other developer’s questions regarding your code to the best of your knowledge.

Owners have rights

• The project owner has the right to make the rules for their code.
• Sub-directory owners can make the rules for their code provided they do not contradict the parent directory’s rules.
• Project owners have the sole right to accept and merge code to the master branch.
• When having a pull request that changes a file, one of the owners of this file must accept the change to be valid for merge.

IMPLEMENTATION

• A company could introduce a completely separate role “Code owner” or have it as an additional responsibility for software developers, it depends on projects size and complexity and the amount of technical debt.
• The code owner could be pulled to any meeting that will result in changes to his software. In the end he knows his code and can help other developers understand the implications of a requested change.
• Pull requests should have hooks to check for code approvals by the corresponding owners. That should prevent any unauthorized changes

IMPLICATIONS

• Having a single person to ask about a project could potentially be very time-consuming for the code owner. This will force them to write their knowledge down and refer other developers to this documentation, so the creation of good documentation is a positive side effect.
• The code owner may add rules that make contribution harder, or set the bar too high for other developers.
• This concept needs a self-driven developer, with a vision for the project, and intrinsic motivation to make their code better.
• After announcing this idea, if at the end some code is still not owned, this is an alarming indicator that nobody wants to maintain it and it must be rewritten.
• Usually slow code reviews are due to the ambiguity of who should review the pull request and the decreasing sense of ownership. Having an explicit owner will solve this, but won’t prevent other people from reviewing the code as usual. The difference is that the only acceptance that is required is the owner’s.

EPILOGUE

The previous strategy might seem like the introduction of a dictatorship to software development and, in some sense, it is! But having a single person make decisions and control a piece of software can lead to significant consistency which will result in a faster development and longer lifetime for software projects.

This strategy is inspired by some communities and projects:

• The Linux kernel project development driven by Linus Torvalds
• Ruby on Rails opinionated development driven by DHH
• Google Is 2 Billion Lines of Code — And It’s All in One Place
• The “Benevolent dictator for life” Wikipedia page