To Pair or Not to Pair
Pair programming. How does it stack up to team programming? Or just individual programming?

This is a very opinionated topic. Those in favor of pair programming swear by it. Both pair programming and team programming have its pros, but like anything else they have their downsides. One of them, unfortunately, is people.

If you think back to places you enjoyed working at, many times it's not the work, but the people you worked with that made work enjoyable. Pair and team programming will put people interaction to the test.

A look at pair programming
Lets assume that all you do is pair programming. Individual programming may occur from time to time, but in general you're pair programming. What your team finds is that they need a work environment that supports this style of programming. So you accommodate them with extra monitors, chairs, keyboards, seating arrangements, etc. Then the team decides how to pair (driver, navigator, operating rules), how often to switch pairing (after a feature is complete, daily, weekly, etc.), how to maintain a context anchor (eg. someone to stay on that feature when switching), and how to assign work.

What you hope to gain
Typical concerns include
Assuming the team gels well, all the pros can occur with very minimal downsides. In fact the idea is that costs aren't increased, but instead are decreased as development is less likely to get stuck and is of higher quality (thus reducing bugs and associated costs).

So why not just pair program?
What actually happens depends heavily on the individuals on the team. In real life and with development, people are hard.

With any development team, certain individuals may not work well with other individuals and personalities come into play. This is heightened with pair programming. Someone may be simply having a bad day. Maybe design or coding directions aren't agreed upon. Then, when it's time to switch pairs, one must explain where things are and why. Sometimes the new person coming to pair doesn't agree with where things stand and design starts over.

With full time pair programming, time must be spent on managing team dynamics. Those that prefer individual programming and putting their head phones on will struggle. Those with strong opinions can cause rifts. New team members, although will likely come up to speed quickly on the code base, must adapt and learn how to "fit in".

Tensions can grow. Job satisfaction may decrease. Productivity is likely to suffer. In the end, full time pair programming struggles to deliver on its promises.


Team programming - an alternative to pairing
So what about full time team programming (also referred to as mobbing)? Many of the same benefits and concerns apply as well. Although those pros and cons may be more elevated. If your team size is relatively small, productivity can remain strong. Larger teams suffer more with productivity and team dynamics.

Without getting into more details with team programming, there are similarities and some slightly different concerns as compared to pairing, but they are there. Again, people and personalities impact the promise of team programming.


All is not lost
Having experience with both pairing and team programming, one should not dismiss the value of these programming styles.

An effective team should mob when it makes sense and pair when it makes sense, but not make either a full time activity.

For example,
In the end, do what works best. Try things out. Adjust, improve, and adapt.