SamSE3/2014SE3 — pull request #1 by SamSE3 (2014-06-05 04:44:05+00:00)
Title: prac 8 checkpoint pair programming

# Intro:
For this project I was paired up with a student form the US study group. We decided that we would code the project in java and use my GitHub repository to store the code. Unfortunately my partner had little had little programming experience so I did much of the actual programming. Non-the-less, the insights he provided more than made up for it.

# Advantages
Some of the Advantages or benefits that I experienced or expect I would experience are:
* Added perspective, it is not possible for one person to analyse a problem from many different angles quickly. An example of this is that I was able to devise an algorithm to calculate the days this year from the number of months using a method that would sum the days from each month (adding 1 for February if it was a leap year) but my partner noted that it was inefficient and that using a running total of the sum of all previous months days and then adding 1 for February if it was a leap year would be better.
* Keeps you on track, working in a team you are more focused on your work, by yourself you can lose track of what is important and get hung up on the little stuff.
* Combined experience, since my partner was inexperienced I was able to help him on the basics of classes and object oriented development. Had the aim been more complicated and his experience greater I believe that this would definitely increase our coding efficiency.
* Increased coding speed. It almost goes without saying that two people can code faster than one.
* Having to communicate about what you are doing forces you to think about it.
* Communication also can help development documentation, comment coding and message like ‘I have done … which does …’

# Disadvantages
Some of the Disadvantages that I experienced or expect I would experience are:
* The flip side of different perspectives is that not everyone will reach the same conclusion to how a problem should be solved. This meant that some sort of initial co-ordinated design might be needed adding project overhead.
* Some parts need to be produced before/after others, method stubs and design may help this, but once again that takes time.
* Communication can be hard and time may be lost in having to explain something.
* Even with good coding and division on workload there will inevitably be overlap and this needs to reconciled.

# My experience
One of the main things I noticed is that communication became paramount, to say what I was doing and to know what my programming partner was doing, so that we could combine our efforts effectively. I can see how it could be almost nightmare-ish if we spent a lot of our time coding the same part and then having to deal with joining this in the repository.

# What I would change
If I could change one thing it would be that he had more programming experience. If I had more time I would probably go the full design root and design a series of method stubs, define the required functionality of each and then divide the workload.

# Conclusion
After this project, though small, I can say that I would definitely use parried programming in future especially if there was a clear division of workload.