Benefits of Practicing Collective Code Ownership

January 27th, 2019 by cedcraftscodes

Collective code ownership, in simple terms, is sharing code and design responsibility among the team members. A sole developer who is working on a piece of a module in a nontrivial project should consider letting other team members look into their code and do necessary refactoring. It is a practice in extreme programming which helps deliver high-quality software and respond to the customer changing needs.

In a workplace with “strong code ownership”, developer tend to not let other developers add functionality, change the approach or refactor as they will be held responsible if something went wrong. In collective code ownership, any developer has the change to modify and refactor the code anytime they want.

Without further ado, here are the benefits of collective code ownership.

Anyone can work on a fix when the one who handles the work is not around.

It is inevitable that someone would not be around for a certain reason, either they are sick or has an important appointment to attend to. When maintaining an existing system, it is unavoidable to have a defect. With collective ownership, any programmer can pitch in and apply the fix as soon as possible. It lessens the impact the bug may have caused as it is more important to meet the user expectation than waiting for the developer who has a brilliant idea but is not around. It also breaks the notion that a person who owns the code is the only one who can modify it.

Create disciplined programmers

Collective code ownership forces a programmer to write better code as he knows that someone is watching him. Always think that the one who will check your code is a psychopath who knows where you live. You have to be more careful when writing codes.

Improves overall code quality, maintainability, and understandability

When a psychopath is looking after your code, do you think you can still write flimsy codes? Definitely not. Other members may not have sufficient domain knowledge but may have better code implementation. With collective code ownership, you have more eyes who look over the codes, thus, lessening the oversight of bugs.

Easier project scheduling

There will be times that developer who is exclusively responsible with the module is around but is handling a much more important task which needs attention. When anyone can work on the project, it helps the project manager to plan the schedule as there is sufficient resource who can handle client requests.

Improves team domain knowledge and experience level

There was a time a team member of mine is not around. No one on the team can provide updates about the project he is currently working on. In the process, one may ask helpful questions that enhance his knowledge and raises a question on possible code smells. With great knowledge comes greater confidence. The entire team should be able to make a change to the entire code as they are responsible for the overall project.

How to start collective code ownership?

You can start by rotating the work across the different module. If you are worried that he may not be able to handle such change, do pair programming.

It would be better if someone will be out of his comfort zone and be familiar with a different domain.

Do proper unit testing and write automated tests. This will provide you are reliable test suite who can watch over your codes.

How to keep it stable?

Practice collective ownership moderately. If a highly skilled developer is handling the item, it may be advantageous to let them be the expert in the subject while exposing them to other parts of the system.

There may be an oversight on the code when one or more developer is doing code changes. The sole expert is responsible to check the codes written by other developers.

Ensure that knowledge is regularly shared as uncertain events may happen. That being the case, you may risk losing the domain knowledge as a person may leave the project anytime.

Spread the love