The one cultural characteristic you need for a healthy codebase

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.

Why code ownership matters

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.

Types of code ownership

There are different types of code ownership, suitable for different situations.

Absolute ownership

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.

Collaborative ownership

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).

Weak ownership
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.

Orphaned code
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.

So what’s the sweet spot?

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.

Benefits will include:

1. Higher coding standards, properly maintained. It's easier to maintain high standards in a small, well-informed group. This applies not just to engineers modifying code they own, but also to reviewing their colleagues' code when it modifies their ownership areas.
2. Easier communication. Explicit and clear ownership means that every engineer in the team knows who's best placed to answer their questions.
3. More focused and impactful refactoring. When you decide to pay back some technical debt, strong code owners are best placed for the job. Use ownership, cohesion, and code churn metrics to triangulate on problem areas in your codebase. Your engineers will use their technical debt budget wisely and they’ll never waste time paying back the wrong technical debts again.
4. The bus factor will never get out of hand. You can use code ownership to inform knowledge-sharing in the organisation. If ownership is too high, assign other engineers to code reviews and tasks that modify the code in question. You'll gradually improve your ownership scores, which will lead to increased code quality and less technical debt.

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.

If you’re looking for a sustainable solution for tech debt management in your engineering team, you need Stepsize. It helps build a culture of code ownership. It’s the world’s first and only bespoke tech debt management tool. Track and manage issues directly from the IDE, and create issues directly linked to code. For engineers, this means no more context-switching and high-quality issues that can be prioritised based on impact and fixed. And because it integrates with Jira, your PM will love it too.

‍Learn how to get started with Stepsize here. It works with Visual Studio, VS Code, JetBrains.