Despite the skill and best intentions of engineers, it seems that an immutable law of software development is that technical debt accumulates until it becomes too much to bear and we have to carve out time for a big refactoring.
We’ve begrudgingly accepted this as part of the software development lifecycle. Is it simply down to a lack of discipline?
I used to think so. Then I met Gareth Visagie, Chief Architect at Snyk.io, who hit me with:
Ownership is a leading indicator of engineering health.
He’s not alone. I’ve been lucky enough to meet some of the best engineers in the world as part of Stepsize’s daily work. When discussing how technical debt is created with top engineers from the likes of Skyscanner, Spotify, Palantir, etc., the same theme came up consistently: ownership.
Recent academic research has shown that code ownership can actually be measured from Git commit activity. The parts of the codebase that receive contributions from many people accumulate cruft over time, while those receiving contributions from fewer people tend to be in a better state.
Credit: Microsoft research
I can already hear some of you screaming that you don't want just one developer being the only person allowed to touch a piece of code—there are nasty downsides to this. I hear you, and that's not what we're proposing.
There are different types of code ownership, suitable for different situations.
It can be fantastic. It can also spell trouble.
Code is considered absolutely owned when the owner is the only engineer who can modify or approve modifications to it, or when the owner is the only person who modified it in the past. It's not the end of the world, but if the engineer ever got run over by a bus, this part of the codebase will be orphaned. You should have a contingency plan.
But there are situations where absolute ownership is acceptable and even recommended. You might want absolute ownership on those ‘if this thing fails we can pack our bags because the business won't be able to pay our salaries or because we're going to prison’ parts of the codebase. In these cases, you may want to consider setting up rules to prevent PR being merged without the approval of the absolute owner.
This means that every engineer is absolutely clear on who they should speak to if they have any questions and that the owner is the best person to review the code.
The code owner is empowered to make decisions relating to code quality and technical debt; they will be held accountable for these decisions using additional supporting metrics such as cohesion and churn (see more in our article about 3 technical debt metrics).
This is the opposite of collaborative ownership and should be avoided in most situations. That being said—and this might be stating the obvious—it's fine if files like package.json don’t have a clear owner. There’s no need to be overzealous.
This is the nasty type of non-ownership, one of the extremes on the code ownership spectrum. It's the one you really don't want. Avoid it at all cost . . . unless it’s code you'll never touch again. But that's pretty rare.
Code is considered orphaned when the main contributor has ceased contributing to the codebase. They may have left the organisation, or moved from coding to management. Either way, you—and your codebase—are in trouble.
But there's a solution for this too. You need to transition the orphaned code to whichever other type of ownership is most appropriate for it. To avoid having any orphaned code in your codebase, make sure that your off-boarding and handover plans include the main owner bringing the new code owners up to speed. Ease them in by automatically assigning them to review pull requests that modify the code. Failing that, you can simply assign code ownership however you see fit.
Whichever method you choose, don't leave orphaned code loitering in your codebase. You never know what might happen when it’s left to its own devices.
Aim for collaborative ownership for the vast majority of the files in your codebase (50%–90% code ownership for any given file), and be more disciplined to increase code ownership and reduce technical debt wherever appropriate.
Like anything that’s worth doing, creating—and sticking to—an engineering culture of code ownership takes time and effort, but it'll pay back in spades. It directly impacts virtually any engineering health KPI you can imagine. Bake it into your culture, and it'll become a giant competitive advantage for the long-term.
Stepsize will help you create a culture of ownership by making the process of managing tech debt simple. Try Stepsize for free!