Collective Ownership

One of the biggest threats to a team's success is politics. Politics at the technical level happen when turf is clearly established. Recognized as an anti-pattern in the book, “Software for your Head”, turf is dangerous as it can send teams spiraling toward disaster while engaged in turf-wars.

Collective Ownership elliminates turf. Everyone on the team owns all of the system. Whoever is best equipped to work on any part of the system is empowered to act. This means that the team shares code collectively. If a defect needs fixing, the first person who knows how to fix it and wants to do so goes ahead. There is no attempt to find someone responsible for the defect.

To aid this practice, teams follow Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point.

Continuous Integration requires team guidelines to be setup that will enable different pairs to integrate their work quickly, giving them confidence to believe in Collective Ownership of code. A Coding Standard should exist so people can easily read all of the code.

Story Test-Driven Development is critical to Collective Ownership – it helps identify defects introduced into a working system due to new modifications. The instant feedback from automated tests provides courage to developers to modify unfamiliar parts of the system.

The design of a system is improved when there are many collaborating minds. Defects and poor designs are easier to acknowledge and correct when blame is shared across the team and not by any individual. Good suggestions are easier to accept when the credit goes to the project community.

Further Reading