Pair programming

A good paper on pair programming from Laurie Williams,  of North Carolina State University here. It is very telling on both the nature and the value of this practice, and emphasises two aspects of it that I feel have yet to be appreciated.

Firstly, pairing is a practice that can be reused all across the development and delivery process. We routinely use a version of it in Agile backlog refinement (when the whole team gets to review the backlog), and it’s plainly implicit in one of the true fundamentals of Agile, namely collaboration. It is striking how much pairing relies on the high levels of experience, humility and professionalism on which Agile rests as a whole too.

Secondly, Williams emphasises the way in which pairing introduces, almost by the back door, a non-Agile practice that was always neglected by traditional lifecycles, namely the review. Yes, there are zillions of reviews going on all the time, but in my pretty broad experience they don’t have the impact they should. Of course, formal reviews don’t sit very well with Agile, but it is impressive how pairing brings peers together for exactly the purpose they strongly resist when asked to do it in the form of a review as such.

Finally, pairing is an excellent way of preventing the growth of technical debt, and as such it is such both a boon in its own right and a serious economy in the process as a whole.

So a treble win for pairing. And probably a lot more too, if you look careful at its links to other Agile practices.


By |2018-01-18T13:08:32+00:00Thursday, August 13 2015|Categories: Agile, All, Process and method, Professionalism, Quality, Technical debt, Verification|0 Comments

About the Author:

Chief Architect,

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?             
error: Agile201 is wholly copyright and copy-protected.