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.

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