If we program independently and then try to combine our results at the
end, we often end up with disaster because no one is on the same page.
However, when we program in pairs, we are on the same page from the
beginning and the end product is better because we can communicate and
collaborate. [Alex]

It is necessary to make careful plans before a team separates into
more than one pair programming team. [Tim]

From the very start, planning needs to be coordinated. Members of a
project need to have a clear common idea of what they're trying to do.
Also, it is important to keep checking in. Going off on different tangents
is very possible. [Rick]

The final exercise was a reminder of how important it is for everyone
in the group to agree on what the plan is.  If you split up and build
all of the modules of functionality separately, you will end up with
multiple projects that are extremely difficult to integrate. [Alexi]

When we kept switching partners, it was a lot easier to build something
that had a cohesive design with the parts of which actually connected.
However, it also showed me that you also need some coming together as a
whole group to compare, especially at the end, before any actual
implementation, as we changed some features in talking to different
group-mates. [Jay]

Good communication among your members is critical to develop coherent
program in more efficient way because you can avoid wasting time and
energy caused from the significant discrepancy in each other's code by
making important decisions together. [Kyung]

Working in pairs works better if you rotate pairs than if you don't,
because after the first pair switch you realize that you're all sitting
right next to each other and you might as well talk as a group anyway. =)
[Heather]

Switching partners lets you spread knowledge throughout the group.
Integration was much easier when we rotated partners than when we did not.
[Janet]