(Not actually Peter and Barry)
Next week, Peter and Barry will be trying out pair programming on a small project. Pair programming is a software engineering technique from Extreme Programming (XP) (an agile framework). There is a lot of confusion in the field about what it means: it’s much more than simply sitting next to each other with one person watching the other person type. Pair programming is actually very structured. The developers share one computer. One person (the driver) with the keyboard writes the tests and codes, and the other developer (the navigator) double-checks the coding, confirms that the pair is proceeding in the best direction, and makes suggestions. The developers are continually thinking aloud: if it’s quiet, something is wrong. Navigators and drivers switch relatively often so that one person is not hogging the keyboard.
Some developers HATE pair programming; other developers swear by it. I have observed an exceptionally productive pair in action. I have also paired successfully as a database developer on the conversion from Marx to SIS. However, I have also seen pairs fail to make it work for a multitude of reasons. It seems that when personalities and skill sets mesh well, two developers pairing can accomplish much more than two developers working independently (research supports this).
Pair programming is a social skill that takes time to learn. You are striving for a cooperative way to work that includes give and take from both partners regardless of corporate status. The best pair programmers know when to say “let’s try your idea first.”
True collaboration, with honesty, trust, and respectful debate, is required.
Resources
- Pair Programming
- Pair Programming Illuminated (on Safari Books, login with OSU username)
- Part II: Getting Started with Pair Programming
- Chapter 27: Seven Habits of Effective Pair Programmers
- Pair Programming chapter in The Art of Agile Development (on Safari Books, login with OSU username)
