BrainBrain View Note

Within a succession of volleys of pros and cons of XP as a programming method, a friend of mine has driven me to try pair programming once again. I say once again, though my previous experiments were few and short lived. Nonetheless my opinion has always been rather strong: I don't consider pair programming to be a valuable exercise.

A brief background to understand my position: I've been doing programming for almost 20 years now, and have worked on a large variety of projects. I like learning new things. I'm happy to learn new methods. But I've also been exposed to a lot of fanciful ideas such as data driven design, top-down design, full coverage, waterfall method, the rational method, UML modeling, TDD, and many more potentially useful methods which all eventually fail due to some unrealistic expectations or some kind of dogmatic crap lining their bindings.

Insofar as pair programming is some kind of cornerstone to XP, one could argue that it can't simply be tried on its own. But that is just what I'm going to do. I consider there is a large enough overlap of my practices with the preaching of XP, and XP doesn't ask us to be perfect, so pair programming should bring us something in our current situation.

I need to use the term us now as my friend has validly pointed out that a core goal of pair programming is to improve the team, not just product, and certainly not just an individual. Business priorities of course do not let us simply ignore the need for individual performance, but for now we'll indulge this effort without such considerations. Perhaps I can be shown that those exact considerations are what pair programming addresses. Perhaps not.

Pair Programming Session 1→