gardners/2014SE3 — pull request #135 by jhaylock (2014-06-12 03:12:05+00:00)
Title: added hayl0017 - github.com/jhaylock/se3prac3/blob/master/pp.txt

Prac 8 - Pair Programming

In this practical we tried out the software development technique called pair programming. This approach to programming was not something I had experienced in the past and I found it to be an interesting approach.
I am not entirely sure if it was faster to do the exercise in a pair or solo. In some ways it was a clear improvement since there where situations where one of us was stuck on how to achieve something, and the other programmer had a good idea on how to proceed so we could keep pushing forward. This was less effective in some circumstances where one programmer had an idea in their head of how something should be done, but had difficulty explaining it to the other person.
There were also instances where we had conflicting ideas on how to go about a particular problem. These difficulties may just be due to the fact that it was the first time we had worked together. I can see how familiarity between the programmers could make it easier to communicate and share ideas, though this could also be limiting if our approaches are too similar. The pair programming technique only works if both participants are communicating, a less expressive person would make it ineffective.
The concept behind pair programming involves one person taking on the role of 'driver' doing the coding while the other person takes on the role of 'navigator' planning the strategic level solutions and the two people switching roles every ten minutes or so. In our pair programming exercise we found ourselves switching much more often or ignoring this structure altogether. We ended up switching roles whenever the driver got stuck on a problem and the navigator had an idea for a solution.
Having two people looking at code as it was entered made noticing mistakes much easier. It occurred many times in our exercise where one of us would enter something incorrectly or be unsure of some requirement and the other participant would jump in and correct the mistake.
While this experience was useful for the short exercise we were undertaking I'm not sure how well it would work on a longer project. The back and forth of roles and constant interjecting might become tedious when programming for extended periods of time. The relative skill levels of the two programmers would probably have a big impact on how well the pair programming went. If one programmer has much more experience than the other they they might take over the project leaving the less experienced participant with nothing to contribute.
I found pair programming to be a very interesting approach. The environment we tested it in may not have been the most idea but it is definitely a concept I would like to explore more, I can see how it would be very beneficial under the right circumstances.