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.

Unit Tests and Collective Ownership

Collective ownership of code requires that an extensive test suite be present. Because engineers are allowed to change any part of the code base, they are likely to break some functionality without realizing it. This problem is mitigated by requiring that any altered code pass the test suite at 100% before it is committed. This ensures that no functionality is lost when a change is made to the system.

Negative Reactions to Collective Ownership

Not everyone in the programming community believes that Collective Ownership is the best solution for managing a code base. Concerns about collective ownership include the thrashing of the code as engineers fight over which solution is best. Additionally, there is some concern that engineers will take less pride in work they do not see as "theirs" and therefore be less motivated.

Continuous Integration

Continuous Integration is a philosophy on how code bases should be altered and generally work in conjunction with Collective Ownership. The basic mindset behind continuous integration is the engineers should hold on to code for as short a time period as possible before committing it back to the code base. This encourages small, incremental changes over big changes to the code base.

Under this philosophy, each engineer should integrate code they are working on at least daily, preferably every few hours. This will result in several integrations per day across the whole team. More so even than Collective Ownership, continuous integration requires an extensive unit test suite to function properly within a team.

Advantages of Continuous Integration

Because it encourages smaller changes to the code base that must be thoroughly tested by the test suite before the can be integrated, continuous integration greatly reduces issues with merging code into the code base.

Additionally, frequent updates by engineers helps to ensure that everyone is working with the latest version of the code base when they begin modifying code. This makes it much less likely that engineers will duplicate functionality or otherwise needlessly rewrite code.

Together, these advantages mean that less time will be wasted fixing conflicts in the code and therefore more time can be spent writing new code and working to complete the project.

Disadvantages of Continuous Integration

The disadvantage of Continuous Integration comes from one of it's requirements, extensive unit testing. If the test suites require a long period of time to verify that the system is still functioning, a lot of time can be used up waiting for these tests to complete. This is compounded because continuous integration encourages small changes to the code base. But, the entire test suite must be run each time a change is to be committed. At it's extreme, this could result in engineers spending more time running tests than on developing code.

Because of this, like Collective Ownership, Continuous Integration does not scale well to very large projects.

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

[5] http://c2.com/cgi/wiki?ThoughtfulReactionsToXp