Code Ownership

Emad Elsaid
May 23, 2017 · 5 min read

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.


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.



Code with shared ownership is uncharted territory

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

An owner can rent part of his property

Owners have responsibilities

You must:

Owners have rights




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:

Blacklane Engineering

Blog posts from our engineering team