CSC/ECE 517 Fall 2007/wiki3 9 mdkt

Note to reviewers:

All prose on this page is original, unless otherwise credited. If you doubt this, please indicate the section that you feel is not original and the source from which you believe it was directly copied. Thank you.

Assignment

Two of the important Agile methodologies that we have not said much about in this course are collective ownership and continuous integration. What are the best definitions or examples you can find? Are these widely practiced? Are they controversial? Are there adherents of other design methodologies who consider them harmful? Investigate, through the Web and through the ACM DL.

Collective Ownership

Definition

“Collective code ownership means that everybody is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code.”

Implications

• Everyone owns all of the code
  • Anyone can change any code anywhere
  • No personal ownership of modules
  • No egoless programming either
• Everyone is permitted access to all the code so everyone has a stake in knowing all of the code
• Requires deserved trust
• Communication is very important. If code is property of the whole team, comments are also used to enforce communication.

Benefits

• A major advantage claimed for collective ownership is that it speeds up the development process, because if an error occurs in the code any programmer may fix it.

• All code gets the benefit of many people's attention, which increases code quality and reduces defects

• Pair programming is usually used in conjunction with collective ownership: by working in different pairs, all the programmers get to see all the parts of the code. Pairing will be more difficult if the code any pair is working on is 'owned' by only one member. The non-owner of the pair may not feel comfortable suggesting or making changes to code that they don't have rights to. In collective ownership the code is ‘owned’ by everyone.

• It requires a lot of interaction (especially with pairing) and verbal communication. It would be difficult for a non-contributing programmer to hide out for long in this environment

Problems with individual ownership that collective ownership addresses

• When code is owned by individuals, required features are often put in the wrong place, as one programmer discovers that he needs a feature somewhere in code that he does not own. The owner is too busy to do it, so the programmer puts the feature in his own code, where it does not belong. This leads to ugly, hard-to-maintain code, full of duplication and with low (bad) cohesion. This is less likely to happen when every programmer is responsible for and has access to every piece of code.
• Individuals could become singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less.
• Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.
• When only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided

Controversies

• By giving every programmer the right to change the code, there is risk of errors being introduced by programmers who think they know what they are doing, but do not foresee certain dependencies

• The practice of quickly dipping into a related piece of code to make a quick change can be dangerous, because quick changes can often times create side-effect bugs.

• Collective ownership could be a problem if people worked blindly on code they did not understand.

• If only collective ownership, and not the other extreme programming practices of pair programming, testing, and coding standards, everyone’s efforts will end in chaos

• Pair programming and collective ownership does not bring out individual contributions (good or bad). Bonus plans and other types of performance rewards may have to be changed.

• Another concern with collective ownership is building expertise with the application. There are limits to the familiarity an individual can have with the codebase. Individual ownership helps solve this problem by limiting the amount of code a programmer creates to promote expertise in certain areas.

Continuous Integration

Definition

"Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible." -Martin Fowler

Examples

The practice of Continuous Integration (CI) started as one of the twelve practices of Extreme Programming (XP). It is made up of several sub-practices:

1. Programmers must commit their changes frequently to the repository (at least daily).
2. Changes will invoke an automated build.
3. The automated build must test the changes

These practices in turn generate (possibly) new dependencies:

1. Use a version-controlled source code repository, such as Subversion or CVS
2. Use a test framework, such as any of the XUnit frameworks.
3. Use an automated tool to build several times per day (see below)

Automated CI Tools

These tools generally build the project at regular intervals. They also integrate with the version repository, report build success or failure, and often integrate with tools to report on test metrics.

• Cruise Control

The first and most popular Java-based tool

• Cruise Control.rb

Cruise Control, the Ruby way

• Continuum

A CI tool used primarily in projects that use the Apache Maven build tool

• Vulcan

Google's answer to CI

Controversies

As with most things, continuous integration has its benefits and drawbacks. The benefits far outweigh the drawbacks, though, so CI is adopted often even in projects that do not use other XP practices.^{2, 3}

Benefits

• Frequent commits ensure that everyone is using the latest version of the code (or as close to it as possible).
• Using a test framework ensures that the changes are tested whenever the project is built. More testing -> bugs are found (and fixed) sooner -> lower cost.
• Since much of the process is automated, team members are automatically kept informed of the state of the project.
• Studies show that undergraduate students who learn about CI have a deeper understanding of source code management (SCM)⁴

Drawbacks

• Although CI is widely used in industry, it is rarely taught in academia.⁵
• CI itself is nearly universally accepted as a good thing, but automated CI tools can be misused. Instead of taking the opportunity to speed up a slow build process, an automated CI tool can be abused as a crutch. Programmers rely on the tool to tell them that the build fails because of their changes, rather than ensuring (before commit) that their changes do not break the build.⁶

References

1. Continuous Integration
2. Motivations and Measurements in an Agile Case Study
3. Agile Customer Engagement: a Longitudinal Qualitative Case Study
4. Assessing Undergraduate Experience of Continuous Integration and Test-Driven Development
5. What We Can Learn from Extreme Programming
6. Why I Don't Like CruiseControl