CSC/ECE 517 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 five 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

Advantages of Collective Ownership

Collective ownership of code has several advantages of single ownership of code. The first is that no bottlenecks are created in the code base. If a change alters the dependencies in the code, any part of the code can be changed by any engineer on the team. Second, teams are bound to gain and lose members over the course of a project. Collective ownership is helpful in this case because a single engineer does not take a large portion of knowledge about the framework with him when he leaves. Additionally, new team members can ease into working on the code base without having a set of classes that they have never seen before assigned exclusively to them.

Disadvantages of Collective Ownership

Collective ownership is of course not perfect and comes with some disadvantages. First is that engineers tend to become attached to code that they have written. If other engineers on the team come in behind and overwrite large portions of code written by another engineer, that engineer may be upset by the alteration of his or her code.

Also collective ownership does not scale smoothly. Large teams, or teams working on large code bases, may run into problems if they attempt to use collective ownership of their code. Large teams run into problems because each engineer on a team is bound to have a slightly different vision of what the final product should look like and how it should behave. It is possible that time will be wasted as each developer adds his or her personal spin to each portion of the code, possibly overriding changes done by others.

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 attempting 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. In this system, each engineer integrates their code at least daily, preferably every few hours. This means that there are several integrations per day. Extensive automated testing is usually required for this system to function properly.

Among the advantages of continuous integration are that greatly reduced integration issues on any given project. This is because engineers do not modify code for long periods of time. It is therefore less likely that changes made by one engineer will greatly conflict with changes made by another engineer. This leads to faster integration of code and less man hours spent fixing conflicts.

The disadvantage of continuous integration is that it requires an extensive testing suite to ensure that the small constant changes do not break existing functionality.

References

[1] http://martinfowler.com/articles/continuousIntegration.html

[2] http://confluence.public.thoughtworks.org/display/CCNET/What+is+Continuous+Integration

[3] http://c2.com/cgi/wiki?CollectiveCodeOwnership

[4] http://www.extremeprogramming.org/rules/collective.html