(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

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) 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)¹.

Best Definition

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

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 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 Kent Beck, collective code ownership means "Anyone can change anything at anytime"³, 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.

Benefit of Collective Code ownership

The most feasible benefit of collective code ownership is to avoid truck factor⁴. 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.

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.³ 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.

Essential concepts to put CCO in practice

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.

Pair programming is essential for code knowledge sharing in XP. 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. ^{5, 6}

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. ^{1, 3, 7}

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)^{3, 8} 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.

Where it is popular and where it is cumbersome

Limitation in programming for the large

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⁹.

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.²

Not always the most efficient

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 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.^{2, 10}

Conflicts with other programming practice guide

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.

The 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. ⁶

The 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.¹¹

Continuous Integration

Shannon's section...

Reference

L. Copeland, Extreme Programming Computerworld; 12/3/2001, Vol. 35 Issue 49, p48, 1p
M. Nordberg III, Managing Code Ownership
Collective Ownership, industrial XP
The Art of Agile Development: Collective Code Ownership
Collective Code Ownership, XPexchange.net
Mark Needham, Collective Code Ownership: Some Thoughts
Collective Ownership, extremeprogramming.org
Collective Code Ownership, Cunningham & Cunningham, Inc.
Lee Copeland, Developers Approach Extreme Programming With Caution. Computerworld, 00104841, 10/22/2001, Vol. 35, Issue 43
Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership

Collective Code Ownership – a misused Agile practice

CSC/ECE 517 Fall 2010/ch6 6e sc

Contents

Collective Ownership and Continuous Integration