CollectiveOwnership

A team member has the right to check out any module and improve it

Definition

A team member has the right to check out any module and improve it. No developer is individually responsible for any one particular module or technology.

Source

C2 Wiki Collective Code Ownership

Discussion

Collective Ownership is one of the enablers of ConstantRefactoring, and gives ultimate flexibility to the developer. Care must be taken to ensure the responsibility is compatible with the increased rights. The team member needs to have sufficient knowledge of any module that he intends to modify. Collective Ownership works best in small teams and in teams that have efficient approaches to knowledge transfer. Of these latter, DevelopingInPairs is a good fit with Collective Ownership. This allows a developer to pair with any developer that is familiar with the module when he desires to make a change to that module. A beneficial side effect is that the developer now becomes more familiar with the module.

Contra-Indications

Collective ownership implies a degree of trust. XP gives the right to modify modules to pairs of developers, with the implied cross-checking and peer review that comes with DevelopingInPairs. There are also assumed to be checks against the possibility of breaking code that previously worked, such as a full set of automated regression tests. Collective Ownership is contra-indicated if there are not adequate checks in place.