Week 8: Pair Programming
Pair Programming and Agile:
Pair programming, or pair development in general, is a theory of two can do it faster and better than one. The justification of using more resources (it does cost more) is one of quality more than speed. When there are two sets of eyes, generally the code will be cleaner, more readable, better structured, less coding errors, etc. Mistakes are picked up earlier and that's the key. The longer errors live in software (through the development process) the more expensive they become to fix.
But I question whether anyone who preaches the benefits of pair-programming actually engages in it themselves. I'm yet to meet someone who proclaims that pair-programming is THE way to develop software and doesn't then go and hide in their office pumping out code on their own. There are of course studies promoting statistics of higher production levels and higher quality, but I could write a report quoting statistical evidence that wearing a hat while coding increases productivity.
As well as the quality benefits, there are some appealing secondary benefits:
- peer pressure to stay focussed (less slashdot),
- improves work-related communication keeping both developers on the same page,
- adds redundancy for when one developer becomes unavailable for one reason or another,
- supplements having a high level of documentation,
- reduces the knowledge gap (if applicable)... sum of 2 brains,
- the co-driver can be actively documenting or jotting down ideas in parallel to being a second pair of eyes.
Pair Programming and me:
It's said that pair programming is not so effective when both members have a similar skill level. However, in my experience it's the opposite. When two developers have a similar skill, working together and bouncing off each other can make them super-productive. Where as if you have one with a higher skill level than another, both parties get disheartened. Generally the one with more skill gets frustrated and ends up driving a lot of the time, while the less skilled developer gets frustrated that the other always comes up with better ideas and better ways of doing things making them feel redundant.
Pair programming definitely has its benefits, but sometimes it works and sometimes it doesn't. It's as much about personalities than anything else and the fluid dynamics of work relationships makes it hard to predict when it will and wont work. If you intend to pair program, then there should be a backup plan for if it doesn't work out. It's not particularly a process failure, just one of the many variables due to human behavior.
Pair programming, or pair development in general, is a theory of two can do it faster and better than one. The justification of using more resources (it does cost more) is one of quality more than speed. When there are two sets of eyes, generally the code will be cleaner, more readable, better structured, less coding errors, etc. Mistakes are picked up earlier and that's the key. The longer errors live in software (through the development process) the more expensive they become to fix.
But I question whether anyone who preaches the benefits of pair-programming actually engages in it themselves. I'm yet to meet someone who proclaims that pair-programming is THE way to develop software and doesn't then go and hide in their office pumping out code on their own. There are of course studies promoting statistics of higher production levels and higher quality, but I could write a report quoting statistical evidence that wearing a hat while coding increases productivity.
As well as the quality benefits, there are some appealing secondary benefits:
- peer pressure to stay focussed (less slashdot),
- improves work-related communication keeping both developers on the same page,
- adds redundancy for when one developer becomes unavailable for one reason or another,
- supplements having a high level of documentation,
- reduces the knowledge gap (if applicable)... sum of 2 brains,
- the co-driver can be actively documenting or jotting down ideas in parallel to being a second pair of eyes.
Pair Programming and me:
It's said that pair programming is not so effective when both members have a similar skill level. However, in my experience it's the opposite. When two developers have a similar skill, working together and bouncing off each other can make them super-productive. Where as if you have one with a higher skill level than another, both parties get disheartened. Generally the one with more skill gets frustrated and ends up driving a lot of the time, while the less skilled developer gets frustrated that the other always comes up with better ideas and better ways of doing things making them feel redundant.
Pair programming definitely has its benefits, but sometimes it works and sometimes it doesn't. It's as much about personalities than anything else and the fluid dynamics of work relationships makes it hard to predict when it will and wont work. If you intend to pair program, then there should be a backup plan for if it doesn't work out. It's not particularly a process failure, just one of the many variables due to human behavior.
posted by Vivski at 5:36 AM
0 Comments:
Post a Comment
<< Home