Nicholas and I are having some misgivings at the moment about whether Pair Programming is all it's cracked up to be. We're not sure whether we're in danger of becoming dogmatic about enforcing it.
One problem is that in our environment requirements and demands on time can be quite fluid, especially as the development team also help our SMS API customers with their integration. This inevitably leads to pairs splitting and less optimal work sessions.
Another is that people are not created equal, there is inevitably a leader in any pair. This can be down to having more development experience, more experience of the part of the system being worked on or just having a more forceful personality.
This translates into a less than optimal contribution from one member of the pair. Especially in the latter case, the less forceful person is likely not to be contributing anyway near to their potential if they're being 'bulldozed' by the stronger party. This isn't necessarily down to arrogance or any malcious intent, it's just they way people are.
So what's the alternative?
We're going to trial working in pairs but on coding two tasks, ideally related to each other, individually. That way you have someone available, on your wavelength to discuss design decisions, patterns, tests, etc but you can knuckle down and get some tests written and functionality produced at your own pace. When you're ready, then you bring in your pair for a review.
This stays true to the concepts of discussion, collaboration and while the code reviews are notquite inline, they are very close to it.
We're running this as an experiment until Christmas. We'll report back
No comments:
Post a Comment