CSC/ECE 517 Fall 2010/ch6 6e sc: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
 
(35 intermediate revisions by 2 users not shown)
Line 1: Line 1:
(THIS PARAGRAPH IS ONLY FOR OUR USE.  WILL BE DELETED BEFORE SUBMISSION.)
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 and Continuous Integration =
= Collective Ownership and Continuous Integration =
In this chapter we will look into two important methodologies of Agile development:  collective ownership and continuous integration.  We will discuss what these methodologies are and provide examples.  We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.
In this chapter we will look into two important methodologies of Agile development:  collective ownership and continuous integration.  We will discuss what these methodologies are and provide examples.  We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.


==Collective Ownership ==
== Collective Ownership ==
Collective ownership, or collective code ownership(CCO), is one of the extreme programming (XP) 12 core practices. Programmer Kent Beck developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corp.'s payroll application. Beck then spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)[[#References|<sup>1</sup>]].
Collective ownership, or collective code ownership(CCO), is one of the [http://en.wikipedia.org/wiki/Extreme_programming_practices extreme programming (XP) twelve core practices]. Programmer [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck] developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corporation's payroll application. Beck later spelled out the development methodology in a book titled <u>Extreme Programming Explained: Embrace Change</u> (Addison-Wesley, 1999)[[#References|<sup>1</sup>]].


=== Best Definition===
=== Best Definition ===
When we talk about ownership, we are generally talking about following 5 factors [[#References|<sup>2</sup>]]
When we talk about ownership, we are generally talking about the following 5 factors [[#References|<sup>2</sup>]]
*Direct benefit from increases in value or generated income<br/>
*Direct benefit from increases in value or generated income<br/>
*Pride in appearance, achievement, and improvement<br/>
*Pride in appearance, achievement, and improvement<br/>
Line 15: Line 12:
*Commitment to long-term involvement<br/>
*Commitment to long-term involvement<br/>
*Potential for successful resale (reuse)<br/>
*Potential for successful resale (reuse)<br/>
Regarding the XP practice as a development practice guide, the collective code ownership doesn't deal with warefare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective code ownership means "Anyone can change anything at anytime"[[#References|<sup>3</sup>]], which works similarly to open source programming. This definition directly deal with the Responsibility for problems, flaws, or routine maintenance, but not saying things about warefare brought by the ownership.<br/>
Regarding the XP practice as a development guide, collective ownership doesn't deal with welfare directly. It gets credit in the virtue of knowledge and development procedure. In the words of [http://en.wikipedia.org/wiki/Kent_Beck Kent Beck], collective ownership means [http://industrialxp.org/collectiveOwnership.html "Anyone can change anything at anytime"][[#References|<sup>3</sup>]], which works similarly to open source programming. This definition directly deal with the responsibility for problems, flaws, or routine maintenance, but not saying things about welfare brought by the ownership.<br/>
 
=== Benefits of Collective Ownership ===
The most feasible benefit of collective ownership is to avoid [http://www.agileadvice.com/archives/2005/05/truck_factor.html truck factor][[#References|<sup>4</sup>]]. The truck factor is used to describe what would happen if a member of the development team gets hit by a truck. For example, the truck factor is one if there is only one person working on a sub-system. If this person were hit on the road, then the odds for the team to lose the knowledge of the sub-system - at least temporarily - is 100%. The truck factor is 0.5 if there are 2 people working on the same project. <br/>
 
Collective ownership enables the knowledge of certain code to be shared within the development team and thus has a low truck factor. This will be very important for a volatile coding team with frequent developers moving in and out.<br/>  


===Benefit of Collective Code ownership ===
To avoid a very high truck factor, collective ownership is also believed to minimize the political turf in the developing team so that development can be more rapid.[[#References|<sup>3</sup>]] This is commonly seen when a developer or small group of developers are doing a subsystem. Then different groups of people would build the obstacles between. To complete a certain function system wide, you would have to consult each of the development groups or individuals one by one. This slows down the development. <br/>
The most feasible benefit of collective code ownership is to avoid truck factor[[#References|<sup>4</sup>]]. The truck factor is used to describe what would happen if one of the development team member gets hit by a truck. For example, the truck factor is one, if there is only one person working on a sub-system. As if this person got hit on the road, then the odds for the team to lose the knowledge of the sub-system at least temparury is 100%. The truck factor is 0.5 if there are 2 person working on the same project. Collective code ownership enables the knowledge of certain code is shared within the development team and thus has a low truck factor. This will be very important for an volatile coding team with frequent developers move in and out.<br/>  


Except to avoid very high truck factor, collective code ownership is also believed to minimize the politics turf in the developing team, so that development could be more rapid.[[#References|<sup>3</sup>]] This is commonly seen when a developer or small group of developer are doing a subsystem. Then different groups of people would build obstacle between. To complete certain function system wide, you have to concult each of these develop groups or individuals one by one. This slows down the development. <br/>
=== Essential Concepts to Implement ===
As mentioned above, collective ownership is not simply an ownership concept in daily life, rather it emphasizes on code knowledge sharing. However, it is the way it is practiced that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effective CCO, pair programming and complete unit test before check in of code changes. <br/>


*[http://en.wikipedia.org/wiki/Pair_programming Pair programming] is essential for code knowledge sharing in XP, but only if the developer who is working on a specific code block is truly knowledgeable of code. A common bad practice is the subsystem is still worked out by one developer, while he 'tells' other developers what he did. This practice doesn't change much.  Pair programming would require frequent partner changes. So in this scenario, each person has the experience of every part of the subsystem. The knowledge of the code is truly shared by all the team members. [[#References|<sup>5, 6</sup>]]<br/>


=== Essential concepts to put CCO in practice===
*Complete [http://en.wikipedia.org/wiki/Unit_testing unit test] is extremely important to writing good quality code. So is it extremely important in CCO consideration. As different developers may have different view points on a certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain subsystems would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|<sup>1, 3, 7</sup>]]<br/>
As mentioned above, collective code ownership is not simply ownership concept in daily life, rather it emphasizes on code knowledge sharing. But it is the way how it is practised that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effecitive CCO, pair programming and complete unit test before check in code changes. <br/>


Pair programming is essential for knowledge sharing. Only if the person who is working on the code block could be said as truly know this code. Common bad practice is that the sub-system is still worked out be one person, while he 'tells' other what he does. This doesn't really make much changes. And pair programming would require frequent partner changes. So in this senario, each person has the experience of every part of the sub system. The knowledge of the code is truely shared by all the team members. [[#References|<sup>5, 6</sup>]]<br/>
As mentioned in many articles, except the two mention above, other practice principles (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browsing tools to check old methods)[[#References|<sup>3, 8</sup>]] are believed to help with building up CCO in development team. Actually, after looking into each of the principles, you will find the help is essentially coming from the two key practices which are coincidentally a part of these other principles.<br/>


Complete unit test is of the key importance to make a good quality code. So is it in CCO consideration. As different developer may have different view point on certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain sub-system would be totally unpredictable. This will only lead the CCO into no ownership chaos. [[#References|<sup>1, 3, 7</sup>]]<br/>
=== Pros and Cons ===
==== Limitation in Programming for the Large Team ====
In the real world, it is the lack of the ability to implement the two practices required inherently in CCO that makes ownership sharing controversial. For a large development team, the overhead for sharing code knowledge could be unacceptably big. In the company that has outsourcing or global development, there is almost no way to perform pair programming and even a simple oral report for code change will be impossible[[#References|<sup>9</sup>]]. <br/>


As mentioned in many articles, except the two mention above, other practise principles, (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browing tools to check old methods)[[#References|<sup>3, 8</sup>]] are believe to help with building up CCO in development team. Actually, after look into each of the principles, you will find the help is essentially coming from the two key practise which is coincidently lying within these other principles.<br/>
Therefore, CCO is considered not good for very large groups, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20 or less developers. If only 3 or 6 people are involved, as in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. Even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|<sup>2</sup>]] <br/>


=== Areas where it is popular and where it is cumbersome ===
==== Not Always the Most Efficient ====
==== Limitation in programming for large business ====
XP practice is mostly focused on light weight but rapid code writing. Therefore it may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. <br/>
In real world, it is the lack of the ability to implement these two practices required inherently in CCO that makes ownership sharing become a little bit controversial. Especially for a large development team, the overhead for sharing code knowledge could be unacceptable big. In the company doing out-sourcing or gloable developing, almost no way to do pair programming and even simple oral report for code change will be impossible[[#References|<sup>9</sup>]]. <br/>


Therefore, CCO is considered not good for very large group, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20- develop. If only 3 or 6 people are involved, in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. And even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.[[#References|<sup>2</sup>]] <br/>
A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kinds of ownership at different development stages. In short, at the inception period, one or two product specialists collect the system requirements and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|<sup>2, 10</sup>]] <br/>


====Not always the most efficient ====
==== Conflicts with Other Programming Practice Guidelines ====
After all, XP practise is mostly focused on light weight but rapid code writing. Therefore may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period. A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the [http://en.wikipedia.org/wiki/Unified_Process unified software development process framework] and make use of different kind of ownership at different development stage. For short, at the inception period, one or two product specialist collects the system requirement and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.[[#References|<sup>2, 10</sup>]] <br/>
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by [http://en.wikipedia.org/wiki/Object-oriented_programming Object Oriented Programming(OOP)] -- information hiding. If each programmer knows each part of the code well, he/she may easily get the idea to change other code implementation outside of his working subsystem. This is considered a bad practice in OOP. For a well designed system, one needs no knowledge of other parts of code. <br/>


====Conflicts with other programming practice guide ====
This is the outcome of the root debate between agile practice and traditional design-first practice. The latter one tends to separate the whole project into smaller ones, and each of the smaller ones don't need the knowledge of other parts.  <br/>
Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by Object Oriented Programming(OOP) -- information hiding. If each programmer well knows each part of the code, he/she may easily get into the idea to change other code implementation out of his working sub-system. This is for sure bad practise considered in OOP, as for a well designed system, one needs no knowledge of other part of code. This is the outcome of the root debate between agile practise and traditional design-first practice. The latter one tends to separate the whole project into small ones, and each of the small one doesn't need the knowledge of other part.  <br/>


===The good CCO example===
=== Good CCO Example===
"A team follow Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. "[[#References|<sup>6</sup>]]<br/>
A team follows Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. [[#References|<sup>6</sup>]]<br/>


===The bad CCO example===
=== Bad CCO Example===
A team with not complete unit test framework and have no submitter's name in the source code repository. Some one gets furious because another incompetent developer is free to make stupid mistakes everyday and not being blamed. Obviously, they are not implementing a good pair programming scheme as well.[[#References|<sup>11</sup>]]<br/>
A team with no complete unit test framework and no submitter name in the source code repository. Someone gets furious because another incompetent developer is free to make stupid mistakes everyday and not be blamed. Obviously, they are not implementing a good pair programming scheme.[[#References|<sup>11</sup>]]<br/>


== Continuous Integration ==
== Continuous Integration ==
Shannon's section...
Continuous Integration (CI) is another core practice of extreme programming.  CI is a process where an application undergoing development is rebuilt and tested automatically and frequently. 
 
=== Best Definition ===
[http://en.wikipedia.org/wiki/Martin_Fowler Martin Fowler] explains it best:  "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. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."[[#References|<sup>13</sup>]]
 
=== Essential Concepts to Implement ===
CI requires the following concepts to implement:[[#References|<sup>12, 13</sup>]]
* A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
* Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
* Daily integration -- Developers should commit working code to the repository mainline at the very least every day.  This makes identifying and resolving code conflicts much easier and quicker.  You know that you only have to look at the latest code changes for bugs or errors.
* Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
* Fast builds -- Rapid feedback is backbone of CI.  The XP guideline states ten minutes.
* Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing.  Different environments allow for the possibility of different results.
* Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
* Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
* Deployment automation -- Scripts should be used to deploy the system to the various environments.  This helps reduce errors and speed up the process of deployment.
 
One popular CI rule states that programmers should integrate at the end of the day and never leave code unintegrated. The build should not be left in a broken state overnight. This rule demands a task planning discipline on the programming teams. If the team's rule is that whoever breaks the build has to fix the build, it will create natural incentive to check code in and build the code often during the day.  These rules help to ensure that CI is utilized to its fullest potential.[[#References|<sup>14</sup>]]
 
=== Continuous Integration Process Flow ===
Below is a diagram of the process flow when using continuous integration.  As discussed in the information above, each of the steps in the process flow should execute multiple times throughout the day.
 
[[Image:CIDiagram.jpg]]
 
=== Benefits of Continuous Integration ===
There are many benefits to using continuous integration.  The time savings of continuous integration instead of deferred integration can be exponential.  Continuous integration takes away that lag at the end of a project that occurs when the integration is deferred.  Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments.  When builds and/or tests fail, you have immediate notification of those failures which allows you to easily find and fix bugs as they occur instead of during the deferred integration period.  This allows you to quickly and efficiently resolve those bugs while the code they pertain to, which you have just recently written, is still fresh in your mind.  Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments.  This ensures that the system you are writing now is exactly what it will be when it is deployed.[[#References|<sup>12, 13</sup>]]
 
=== Pros and Cons ===
Continuous integration is a popular and important aspect of the Agile and XP methodologies.  Many shops are moving toward adopting these design principles and look at continuous integration as one of the most rewarding perks of the methodologies.  It can greatly increase time saving during all aspects of the [http://en.wikipedia.org/wiki/Software_development_process software development life cycle]. From the initial requirements gathering to the final deployment of the completed project, continuous integration saves time which in turn saves money. Projects can be completed in a more timely manner which also generates a saving in project budget.


== Reference ==
Continuous integration can become cumbersome in a large application project since you need to have multiple environments set up to mirror the production environment.  You can easily spend the savings you would gain from the shortened time frame on the infrastructure costs associated with the multiple clone environments.
 
=== Good Example ===
A development team utilizes a source repository where all modified code is checked in as modules are written.  On check-in, an automated build process executes and then notifies the team of the status of the build by email.
 
=== Bad Example ===
In my opinion, if you follow all the essential concepts of continuous integration as outlined above, you should not have a bad example.  Even if one person is doing all the development, by checking in the code often and running automated builds against that code, problems and errors will surface quickly.  Problems will arise when you have a rogue programmer who does not follow the integration rules or if you omit any of the essential concepts.
 
= References =
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p  
#[http://web.ebscohost.com.www.lib.ncsu.edu:2048/ehost/detail?vid=9&hid=104&sid=e34a3e29-ce87-4658-9f49-d5196bfc2504%40sessionmgr112&bdata=JnNpdGU9ZWhvc3QtbGl2ZSZzY29wZT1zaXRl#db=aph&AN=5696081 L. Copeland, Extreme Programming] Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p  
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
#[http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01184163 M. Nordberg III, Managing Code Ownership]
Line 64: Line 102:
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.cmcrossroads.com/agile-scm/6757-situational-code-ownership-dynamically-balancing-individual-vs-collective-ownership Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#[http://www.simonlin.ca/2007/07/17/collective-code-ownership-a-misused-agile-practice/ Collective Code Ownership – a misused Agile practice]
#"Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
#[http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration, Martin Fowler]
#[http://www.versionone.com/Agile101/Continuous_Integration.asp Continuous Integration, VersionOne]

Latest revision as of 01:53, 27 November 2010

Collective Ownership and Continuous Integration

In this chapter we will look into two important methodologies of Agile development: collective ownership and continuous integration. We will discuss what these methodologies are and provide examples. We will discuss the practice and acceptance of these methodologies as well as any drawbacks they have.

Collective Ownership

Collective ownership, or collective code ownership(CCO), is one of the extreme programming (XP) twelve core practices. Programmer Kent Beck developed extreme programming (XP) while serving as project leader on Chrysler Comprehensive Compensation (C3), a long-term project to rewrite Chrysler Corporation's payroll application. Beck later spelled out the development methodology in a book titled Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)1.

Best Definition

When we talk about ownership, we are generally talking about the following 5 factors 2

  • Direct benefit from increases in value or generated income
  • Pride in appearance, achievement, and improvement
  • Responsibility for problems, flaws, or routine maintenance
  • Commitment to long-term involvement
  • Potential for successful resale (reuse)

Regarding the XP practice as a development guide, collective ownership doesn't deal with welfare directly. It gets credit in the virtue of knowledge and development procedure. In the words of Kent Beck, collective ownership means "Anyone can change anything at anytime"3, which works similarly to open source programming. This definition directly deal with the responsibility for problems, flaws, or routine maintenance, but not saying things about welfare brought by the ownership.

Benefits of Collective Ownership

The most feasible benefit of collective ownership is to avoid truck factor4. The truck factor is used to describe what would happen if a member of the development team gets hit by a truck. For example, the truck factor is one if there is only one person working on a sub-system. If this person were hit on the road, then the odds for the team to lose the knowledge of the sub-system - at least temporarily - is 100%. The truck factor is 0.5 if there are 2 people working on the same project.

Collective ownership enables the knowledge of certain code to be shared within the development team and thus has a low truck factor. This will be very important for a volatile coding team with frequent developers moving in and out.

To avoid a very high truck factor, collective ownership is also believed to minimize the political turf in the developing team so that development can be more rapid.3 This is commonly seen when a developer or small group of developers are doing a subsystem. Then different groups of people would build the obstacles between. To complete a certain function system wide, you would have to consult each of the development groups or individuals one by one. This slows down the development.

Essential Concepts to Implement

As mentioned above, collective ownership is not simply an ownership concept in daily life, rather it emphasizes on code knowledge sharing. However, it is the way it is practiced that makes it controversial. Typically it will have two other principles to serve as the most fundamental support to ensure an effective CCO, pair programming and complete unit test before check in of code changes.

  • Pair programming is essential for code knowledge sharing in XP, but only if the developer who is working on a specific code block is truly knowledgeable of code. A common bad practice is the subsystem is still worked out by one developer, while he 'tells' other developers what he did. This practice doesn't change much. Pair programming would require frequent partner changes. So in this scenario, each person has the experience of every part of the subsystem. The knowledge of the code is truly shared by all the team members. 5, 6
  • Complete unit test is extremely important to writing good quality code. So is it extremely important in CCO consideration. As different developers may have different view points on a certain code segment, if there is no test framework to serve as a coding standard for each function, the behavior of certain subsystems would be totally unpredictable. This will only lead the CCO into no ownership chaos. 1, 3, 7

As mentioned in many articles, except the two mention above, other practice principles (including but not limited to continuous integration, code management tools like SVN, powerful refactoring and browsing tools to check old methods)3, 8 are believed to help with building up CCO in development team. Actually, after looking into each of the principles, you will find the help is essentially coming from the two key practices which are coincidentally a part of these other principles.

Pros and Cons

Limitation in Programming for the Large Team

In the real world, it is the lack of the ability to implement the two practices required inherently in CCO that makes ownership sharing controversial. For a large development team, the overhead for sharing code knowledge could be unacceptably big. In the company that has outsourcing or global development, there is almost no way to perform pair programming and even a simple oral report for code change will be impossible9.

Therefore, CCO is considered not good for very large groups, such as 100+. In fact, most people would consider it is an effective coding practice if there are only 20 or less developers. If only 3 or 6 people are involved, as in the most common cases, it will get the most positive comments. On the other hand, for a large number of developers, it will be hard to carry on a well focused system skeleton. Even on the contrary to the initial goodwill, it will be hard to establish the responsibility for tasks or problems.2

Not Always the Most Efficient

XP practice is mostly focused on light weight but rapid code writing. Therefore it may not have the best effect for use cases collection, architecture design or after production maintenance. This will give trouble to a whole project release period.

A more advanced idea on code ownership is dynamic code ownership. It focuses on the whole development period under the unified software development process framework and make use of different kinds of ownership at different development stages. In short, at the inception period, one or two product specialists collect the system requirements and build up the documentation. Then several experienced chief architects make up the blue print for the whole project. Further increasing the development team, the project runs into code writing session and CCO is implemented. After production release, only a small portion of people is needed to do maintenance.2, 10

Conflicts with Other Programming Practice Guidelines

Except not very suitable for whole development period and large development teams, without careful training of each programmer, it can easily break the brief hold by Object Oriented Programming(OOP) -- information hiding. If each programmer knows each part of the code well, he/she may easily get the idea to change other code implementation outside of his working subsystem. This is considered a bad practice in OOP. For a well designed system, one needs no knowledge of other parts of code.

This is the outcome of the root debate between agile practice and traditional design-first practice. The latter one tends to separate the whole project into smaller ones, and each of the smaller ones don't need the knowledge of other parts.

Good CCO Example

A team follows Continuous Integration, Pairing, Story Test-Driven Development and Coding Standard. As programmers work in pairs, at any point, two people will know about a part of the system. Frequently rotating pairs helps diffuse knowledge across the team. After a point, it would be impossible to associate one programmer with any portion of the system, as everyone on the team has worked on it at some point. 6

Bad CCO Example

A team with no complete unit test framework and no submitter name in the source code repository. Someone gets furious because another incompetent developer is free to make stupid mistakes everyday and not be blamed. Obviously, they are not implementing a good pair programming scheme.11

Continuous Integration

Continuous Integration (CI) is another core practice of extreme programming. CI is a process where an application undergoing development is rebuilt and tested automatically and frequently.

Best Definition

Martin Fowler explains it best: "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. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly."13

Essential Concepts to Implement

CI requires the following concepts to implement:12, 13

  • A single repository -- A decent source code management system must contain all the code for the application and be used exclusively and correctly by the development team.
  • Automated builds that test themselves -- An automated build process that builds the entire application and then performs Unit Tests and Performance Analysis
  • Daily integration -- Developers should commit working code to the repository mainline at the very least every day. This makes identifying and resolving code conflicts much easier and quicker. You know that you only have to look at the latest code changes for bugs or errors.
  • Every integration to the mainline builds the application on an integration machine -- Only after the mainline build is successful should a code integration be considered successful.
  • Fast builds -- Rapid feedback is backbone of CI. The XP guideline states ten minutes.
  • Testing occurs in a clone of the production environment -- to identify the problems that will occur in production is the essence of testing. Different environments allow for the possibility of different results.
  • Latest executable is available for everyone -- Everyone involved with the development should have the ability to get and execute the the latest executable.
  • Communicate what's happening -- Everyone should be able to easily see the state of the system, the changes made, and the state of the mainline build.
  • Deployment automation -- Scripts should be used to deploy the system to the various environments. This helps reduce errors and speed up the process of deployment.

One popular CI rule states that programmers should integrate at the end of the day and never leave code unintegrated. The build should not be left in a broken state overnight. This rule demands a task planning discipline on the programming teams. If the team's rule is that whoever breaks the build has to fix the build, it will create natural incentive to check code in and build the code often during the day. These rules help to ensure that CI is utilized to its fullest potential.14

Continuous Integration Process Flow

Below is a diagram of the process flow when using continuous integration. As discussed in the information above, each of the steps in the process flow should execute multiple times throughout the day.

Benefits of Continuous Integration

There are many benefits to using continuous integration. The time savings of continuous integration instead of deferred integration can be exponential. Continuous integration takes away that lag at the end of a project that occurs when the integration is deferred. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. When builds and/or tests fail, you have immediate notification of those failures which allows you to easily find and fix bugs as they occur instead of during the deferred integration period. This allows you to quickly and efficiently resolve those bugs while the code they pertain to, which you have just recently written, is still fresh in your mind. Building and testing in a clean environment that mirrors the production environment eliminates the inconsistency of individual developer and test environments. This ensures that the system you are writing now is exactly what it will be when it is deployed.12, 13

Pros and Cons

Continuous integration is a popular and important aspect of the Agile and XP methodologies. Many shops are moving toward adopting these design principles and look at continuous integration as one of the most rewarding perks of the methodologies. It can greatly increase time saving during all aspects of the software development life cycle. From the initial requirements gathering to the final deployment of the completed project, continuous integration saves time which in turn saves money. Projects can be completed in a more timely manner which also generates a saving in project budget.

Continuous integration can become cumbersome in a large application project since you need to have multiple environments set up to mirror the production environment. You can easily spend the savings you would gain from the shortened time frame on the infrastructure costs associated with the multiple clone environments.

Good Example

A development team utilizes a source repository where all modified code is checked in as modules are written. On check-in, an automated build process executes and then notifies the team of the status of the build by email.

Bad Example

In my opinion, if you follow all the essential concepts of continuous integration as outlined above, you should not have a bad example. Even if one person is doing all the development, by checking in the code often and running automated builds against that code, problems and errors will surface quickly. Problems will arise when you have a rogue programmer who does not follow the integration rules or if you omit any of the essential concepts.

References

  1. L. Copeland, Extreme Programming Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
  2. M. Nordberg III, Managing Code Ownership
  3. Collective Ownership, industrial XP
  4. The Art of Agile Development: Collective Code Ownership
  5. Collective Code Ownership, XPexchange.net
  6. Mark Needham, Collective Code Ownership: Some Thoughts
  7. Collective Ownership, extremeprogramming.org
  8. Collective Code Ownership, Cunningham & Cunningham, Inc.
  9. Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
  10. Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership
  11. Collective Code Ownership – a misused Agile practice
  12. "Continuous Integration & Performance Testing" Haines, Steven. Dr. Dobb's Journal, March 2008.
  13. Continuous Integration, Martin Fowler
  14. Continuous Integration, VersionOne