Extreme Programming Practice

Collective Code Ownership

The concept of Collective Code Ownership points out to the fact that in an agile software development process, no single member of the whole team owns any specific part of the source code. Therefore, any member of the team can contribute a fresh idea to the project that's meant to improve the design of the software and fix any bugs in the project. In the process, there is a consistent application of coding standards and each member of the team contributes in a manner that can be deciphered by any member of the whole team. Any new versions created by any member of the team that is incomprehensible are replaced by simpler versions that can be understood by all the members involved in the process.

Collective code ownership makes it possible for pair programming and refactoring in the software building process and substantially decreasing the truck factor of the project. The team can be able to complete the task at hand with any of the members being absent for any given reason. This is enabled by each member of the development team creating a unit test to ensure that his/her code’s functionality is not tampered with. By providing that any revised code is subjected to all unit tests - to which it has to pass, i.e., by 100% entirely - before being released, unit tests take away the necessity of having any form of individual code ownership.

Once put in place, unit tests make it possible for any person working in the team to apply any change to the source code without affecting the overall functionality, and with the confidence that any new changes by other members of the team won’t affect his/her code. Since the team works towards a deadline, collective ownership of codes, through unit tests, ensures that versions that are incompatible with the team’s codes are fixed as soon as they develop. This proves to be more efficient as compared to correction of the whole codebase as the deadline looms.

The benefits associated with this practice are:

Everyone feels responsible

First, each individual will feel accountable and culpable for the overall quality of the final product of the whole team and will, therefore, strive to make the project a success.

Reduce risks

There is a significant reduction in the risk associated with absenteeism and unavailability of any member of the team such that the project won’t be hindered.

Solid judgments

Thirdly, the final design of the project will be arrived at with the right technical judgment calls.

Sharing Knowledge

Finally, there will be a good transfer and sharing of technical knowledge among the team members.

The primary limitation of Collective Code Ownership is the notion that having everyone responsible for the quality of the software is similar to having no single individual responsible. No only person will voluntary accept responsibility if the software is not a success and they all may end up denying the project.