Four ways to do pair programming

After we’ve covered the typed of developers I pair programmed with I want to explain how pair programming can be done – based only on my observations:

Turn based

The idea is very simple – you change places, after a predetermined interval. Whoever wrote code (driver) becomes the one who reviews the code (passenger) and vise versa. You could switch places each time you finish a feature or every 30 seconds it’s up to you. The important thing is that you do switch roles according to some event you both agree on.

Obviously using this method keeps both developers interested in the code and should help avoiding the situation where only one developer write the code while the other slowly falls asleep.

Tester – Coder

This is one of my favorites, when writing test first design (TDD) one developer’s objective is to write a test that fails, the second developer need to make that test pass by writing the minimum required code. You can switch roles every now and then so that both of you get to write the feature (and tests).

This is also a good way to teach test driven development to your team - by example.

King of the hill

However grabs the keyboard first writes the code. If he stops or slows the other developer can grab the keyboard (trying not to cause any serious harm to his fellow coder) and continue from there. Oddly enough I’ve seen some pairs where this method actually worked.

Just remember to make sure that both of you feel conferrable working this way otherwise you might offend your co-worker.

One mind – four hands

This method is quite rare, in fact I’ve only seen this kind of synergy a couple of times in the past. Both developers think so similarly that they instantly understand each other’s code without any need to talk or explain what was just done.

One developer writes code while the other reviews it and when one of them tires of his/hers current role they switch roles without more than a node of the head.

The problem is that it can only work if both of you think the same way, meaning you might still make mistakes you can make on your own.

This ends my short observations of the elusive practice of pair programming (at least for now).

I’m sure there are a lot of other ways of doing pair programming – so please enlighten me and tell me know how do you do it?

Labels: Agile