CSC/ECE 506 Fall 2007/wiki3 9 sm

Collective Ownership

In a software project, collective ownership of the code implies that any code written does not belong to any particular engineer. This means that anyone working on the project can modify any piece of code that has been previously written. According to Cunningham & Cunningham, Inc., a consulting firm specialized in object-oriented programming, there are several requirements to make Collective ownership work well:

• All engineers use the same coding standards
• The project use code management tools to detect and resolve conflicts
• A comprehensive suite of unit tests exists
• Powerful browsing and refactoring tools to find references to old methods and replace them with the new
• Continuous Integration, so that conflicts are rare

The advantages of collective ownership are that no one on the project has to depend on another engineer to implement a set of changes; they can simply make those changes themselves. Additionally, becuase all engineers work on all sections of the code, the loss of a single engineer should not hinder development as much.

Collective ownership also has some disadvantages. Because all engineers can modify code, people can become upset when someone modifies code that they have written. Additionally, Collective ownership can run into problems with larger teams; if fifty engineers can modify any file in the project, tracking changes can become problematic.

Continuous Integration

Continuous Integration refers to the idea that instead of engineers modifying a set of code over a long period of time and then attepting to merge that back into to main project code, code should be held for only a brief period of time and then integrated back into the main branch as soon as possible.