When programming teams try to get things done faster, they use more people.  Unfortunately, this does not always work.  As has been explained by others, more people create more opportunities to loose or corrupt information as it is transferred.  At every point of exchange, there is a new opportunity for error to be added to the flow of information, and with each new person there are many more points of exchange.

Based on this, it could be argued that the best way to make software is to do it alone.

Many teams today solve this problem by dividing the work up among individual programmers.  In order to do this, architecture must be pre-determined so that strong interfaces can be defined between the parts that are divided up.  That way, when each programmer is done, the work can be stitched together at the interfaces.

This might be fine except that, often, the architecture that is designed before the software starts is not adequate.  This method also does not take into account issues caused by programmer turn-over or future maintenance.  This method can tend to create a business addiction to programmers because only single individuals understand the system components.

Another issue is the ability to see opportunities for re-use.  It is nearly impossible for the architect to see the opportunities for re-use before the code is written.  This can create software bloat and multiple implementations in one system of the same behavior.

Pair programming attempts to solve the one-and-only-one programmer problem by developing two-by-two and switching frequently.  This creates an opportunity for something that eXtreme Programming calls "collective code ownership."

Collective code ownership is the gem produced by the practice of pair programming.  Because programmers work together on one thing, explaining what took place is much easier.  The faster the pairs switch, the less time passes between the time that something was created and the time that the knowledge is transferred to others who did not witness the work taking place.  Everyone becomes an expert on the whole code base in time.   The code created by the pair programming discipline is often of very high quality.  I hope to discuss this in a future post.  This is an important part of the switching process.

This allows teams to change over time with minimal consequence.  Members of the team can go on vacation, get sick, be added and even be removed if necessary without jeopardizing the project.  Of course changes will always have an effect.  Time is required to bring programmers up to speed so many changes during the course of the project can slow the team down considerably.  Even so, pair programming can be used to get the project back up to speed quickly.

Since all developers look at all parts of the code, opportunities for architectural change appear as "refactoring" possibilities.  I hope to talk more about this in future posts as well.