Exclusive code ownership (why it’s bad and what to do with it)

In December 2016, a front-end developer left a team where I work. Apart from other changes, this created an issue. When he was working, the project had a couple of complex modules we were developing with him together. When he left, I realized that only I am able to work with them – other two team members knew nothing about how these modules function. This is called “exclusive code ownership”, and it’s bad in the long term, so I had to start fixing this. Here’s why it’s bad and what to do with it.

🖐 🔮

Problems

Bus factor

Imagine there’s a complex module in your project that only you work with, and you’re hit by a bus tomorrow. Will the team be able to continue developing this module the next day? Most likely no. This means the bus factor of your team is 1 – that is, it’s enough to kill remove a single developer from the project to severely slow or even stop its development.

Until recently, our project has been heavily relying on a custom front-end framework that was developed by only a single team member. No other developers knew its inner parts, and only a couple of them knew it deep enough. This meant the bus factor of the whole front-end team was just one. This, along with other issues, led us to migrate from this custom framework to React in 2016.

Bottlenecks

If there’s a module in the project that you exclusively own, then, regardless of the team size, only you will be able to make changes in it. If tomorrow you receive 5 critical issues related to this part, there’ll be nobody to help you. You may even slow down your team if these critical issues block them.

We had this problem when a part of our front-end infrastructure changed, and this broke builds for the whole team. Because it was only me who knew how all this stuff works, I had to fix the problems one-by-one. If other team members knew this, they could’ve helped me bring everything back sooner.

Leaving is hard

If once you decide to leave the project, you’ll have to transfer all your unique knowledge about how these parts work to other team members. Depending on the knowledge size, this can take significant time, and it still will be less effective than if other members had real experience with the code.

You create risk and slow down delivery

What to do

Documentation and maintainability

You have probably heard this advice for a lot of times, but it’s never bad to repeat it again. Make your code documented and maintainable. This includes code cleanliness, inline comments, and external documentation.

It’s your choice how much to document the code. I usually try to make it self-documenting and add comments only if the purpose of the code or the decisions behind it are still unclear. Also, remember that self-documenting code is better than comments, and comments are better than external documentation. People occasionally forget to update the comments and often forget to update the external documentation, so the only up-to-date source of information is code.

Commit messages

In my experience, writing detailed commit messages is very underestimated. I’m sure that one of the best ways to share your code knowledge is to include it into your commits. Once you commit something, it stays in the history forever, and tools like git blame help you to easily find which commit changed the specific lines. This means that even if you leave the project, the other developer that will work with the piece you’ve written will be able to git blame the code and see why you made this or that change.

What to write in a good commit message? Well, this is one of the examples from my project I like (I wrote this so I like it, pretty obvious):

Look, this commit includes:

  • the issue number (so that another developer could go and see the business requirements behind the change),
  • the short description of the change (which is usual),
  • and the longer text that explains the commit.

The last part is exactly where you put your code knowledge. Answer why you did the changes. Explain the background that could be unclear to another developer in the half of the year. Document the limitations that your solution has and the issues it creates (if any). Include everything else that you consider significant.

Follow to this Caleb Thompson’s article if you want to read more about good commit messages (especially, take a look at point 4). Also, kudos to Andrey Listochkin for giving the advice about this in one of his talks.

Processes

If you’re a team lead, and you realize that you have this problem in your team, you can use your power to change this:

  1. Find what modules are exclusively owned by someone.
  2. Find what tasks you can give to other team members so that they get experience with these modules.
  3. Ask the module owner to introduce developers that will work with the tasks into the module code.

If you’re a regular developer, and you realize your team has this problem, talk with your team lead. Feel free to show them this article.

Also, this should be solved by introducing mandatory code review or pair programming, though we haven’t practiced this ourselves.

Docs, commit messages, processes

So, well, the checklist:

  • Write self-documenting code
  • Use comments when it’s necessary
  • Write good commit messages answering “why”, not only “what”
  • Involve other team members into working with the code

Follow me on Twitter: @iamakulov

Plus
Share
Send
Pin
2017  
2 comments
Aliaksei Zhynhiarouski

As you wrote, you know about the code, that he wrote, and I’m sure rather deeply. So its not really exclusive ownership. I’m understand and fully agreed with your point, but not all developers should know everything about all parts of the system. They just should be able to understand in short term what this all about and fix the problem, if needed.
Another thing — DDD approuch, where some team members work really exclusively with the specific domain(read code), and this is OK. I can share experience from my current project, when lead developer of several services left company, he made two days training for me(as new lead of this domain) about all things that he knows. And this is enough.
Of course there is documentation, and other staff exist . But then, understanding risks of my own exclusive knowledge ownership – I start made PR with some part of major new functionality and ask them all to review. Just for understanding what this all about. And this works, they already was able to fix some problems without me and diving deep into domain specific parts.
The same for me, I didn’t know deeply about another part of the system, but PR helped me to be sure that if needed – I will be able to fix and improve. We are all skilled engineers, and should be able understand unknown code. Even written with unknown language or technology. At least understand how to deal with problem after half an hour.
TLDR: the problem exists almost for all projects, your was to eliminate it fully correct, but you, and your teammates should be smart enough to deal with unknown/bad/undocumented code.

Your comment
won’t be published

HTML will not work

Ctrl + Enter