40   Practice Collective Ownership

“Don’t worry about that crippling bug; Joe will fix it when he gets back from vacation next week. Just work around it until then.”

Any nontrivial application requires collaborative effort to develop. In that context, there’s no good reason to take territorial ownership of code. Any team members who understand a piece of code should be able to work on it. You increase risk by keeping a piece of code exclusively in the hands of a single developer.

Solving problems and making the application meet its users’ expectations are more important than deciding who has the most brilliant idea, or, for that matter, whose implementation stinks.

When multiple people work with code, the code is constantly checked, refactored, and maintained. If a fix is needed, any one of the developers can pitch in to get the work done. Project scheduling becomes easier when more than one person can comfortably work with different parts of your application code.

You’ll find that the overall knowledge and experience level of the people in the team improves when you rotate them through tasks, giving them the opportunity to work with different parts of the application. When Joe picks up code that Sally wrote, he may refactor it, ironing out issues that need attention. He will ask useful questions while trying to understand the code, providing significant early insight into problems.

From the other side, knowing that others are going to work on your code means you’ll be more disciplined. You have to be more careful if you know others are watching.

You might argue that if a developer is exclusively assigned to work on one area, then he is going to be highly proficient in it, leading to faster development. That’s true, but in the long term, you gain benefits by having multiple eyes look at a piece of code. It helps improve the overall quality of the code, it’s easier to maintain and understand, and the errors decrease.

Emphasize collective ownership of code. Rotate developers across different modules and tasks in different areas of the system.

What It Feels Like

You feel comfortable working on most any part of the project.

Keeping Your Balance

• Don’t accidentally lose expertise on your team. If one developer is highly skilled in an area, it may be advantageous to keep them as the resident expert in that subject while still exposing them to the rest of the system.

• In a large project it can get very messy if everyone randomly changes everything all the time. Collective ownership is not a license to hack wildly.

• You don’t need to know every detail of every part of the project, but you shouldn’t be scared away from any part of the system either.

• There are special occasions when you don’t want collective ownership. Perhaps the code requires specialized, specific problem-domain knowledge, such as in a hard real-time control system. In these cases, you may find that too many cooks spoil the broth.

• People do occasionally get run over by buses or suffer other sudden calamities, including getting hired by the competition. When you don’t share knowledge on the team, you risk losing it entirely.