Software Reality
Extreme Programming

Site Map

XP Central
Case Against... Songs

Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:

Extreme Programming

Collective Ownership, Oral Documentation, and Scalability: The Perfect Storm

By Matt Stephens
July 13, 2003

As we explore in this article, and in the upcoming book Extreme Programming Refactored, XP consists of some symbiotic practices, which when used together build on each other's strengths and compensate for each other's weaknesses. Unfortunately, the latter quality can be a problem - if one of the practices fails, the others become much more likely to fail as well.

Two of the XP practices are particularly reliant on each other: oral documentation and collective ownership.

Oral Documentation

So-called "oral documentation" is the concept that very little documentation needs to be written down in a permanent form, because the team is colocated and collectively knows everything about the project - so if you need to find something out, just ask someone else in the room. Magic!

This would of course be a potential problem, if the project knowledge was not sufficiently dispersed among the team. So XP relies heavily on collective ownership to help make this happen.

Collective Ownership (vs. Individual Ownership)

Collective ownership simply means that everybody has equal ownership of the project code. There is no specialisation. This practice is vital for refactoring in XP to work, because anybody needs to be able to dive into any piece of code and change it, in order to complete their particular refactoring.

The reverse of collective ownership is individual ownership. When using individual ownership, a danger that many projects face is that individuals become singularly responsible for specific areas of the project. On the surface, this seems as if it could work. It's certainly an efficient arrangement: no one needs to waste time communicating knowledge of his area of the product to anyone else, so he can devote all his time to creating it.

There are some dangers, though. First of all, what if one of the individuals 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. XPers sometimes use the phrase "truck number", meaning the minimum number of people who have to be hit by a truck to cause the project to fail. XP claims to raise the truck number via pairing, osmotic communication, and so on, although our feeling is that XP lowers the truck number because not enough information is written down.

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.

To defeat these sorts of problems, XP promotes collective ownership - the idea that everybody is responsible for the entire codebase. In other words, anyone can go and change any part of the code. If someone sees something she thinks is awry, she just goes in and changes it. Although this idea has . . . merit, a more refined approach is possible (see later in this article).

XP's answer is that with sufficiently high levels of communication, these scenarios are less likely to happen. In his book Refactoring: Improving the Design of Existing Code, Martin Fowler writes the following:

"The big refactorings require a degree of agreement among the entire programming team that isn't needed with the smaller refactorings. The big refactorings set the direction for many, many changes. The whole team has to recognize that one of the big refactorings is "in play" and make their moves accordingly."

This is fine for small projects; however, as the project scales up, with more and more developers involved, so the cost of communication increases.

The Third Front: Scalability

As we've seen, oral documentation relies heavily on collective ownership to prevent it from failing. Then in turn, collective ownership relies on there being a colocated team. But what if the team is too large to fit in one room? What if there's more than one team?

The issues with individual ownership arise because only one person knows about a particular area of the project, so the answer is simply to make sure that someone else knows that area as well. The extreme realisation of this is of course collective ownership.

However, the issues with collective ownership arise because the practice relies on small, tightly knit teams with a high level of communication. This isn't good for large projects. (Collective ownership also relies on pair rotation - another practice which becomes more difficult to manage as the project grows in size).

When the project is divided into separate teams (probably in separate rooms), the question arises: does collective ownership span the entire project, or is it limited to individual teams? Currently, XP does not really answer this question. We hope that the answer would be individual teams - but then, some extra communication overhead must be put in place to prevent the aforementioned problems from occurring.

So, the ideal solution is somewhere between the two - that is, in a large-scale multi-team project, collective ownership should span neither the entire project nor be limited just to a single team. It's really just a case of approaching the problem intelligently: don't go to extremes "just because".

Conclusion: How to Sail Around the Storm

To achieve the ideal "middle ground", in which there is collective ownership but where the project doesn't outright rely on this practice to avoid failing, some easy to maintain documentation is vital.

In an ideal project, somebody will be available as a documentation mentor, actively ensuring that all the design documentation is of a sufficient quality - in other words, that the documentation is clear and descriptive. It should be sufficiently "lightweight" that it can be actively maintained without too much work (so that it does not lag too far behind day-to-day changes in the design), yet sufficiently expressive and unambiguous that it does its job.

A lot of the issues introduced in this article are discussed in more detail, in the upcoming book Extreme Programming Refactored.

Software Reality XP Forum

<< Back to XP Central

<< Back to Lifecycle

All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright 1998 onwards Matt Stephens. ALL RIGHTS RESERVED.