Response to Why Pair Programming Is The Best Development Practice?

Response to by s1369981.

Summary of article

The author discusses why pair programming is the best development practice. First of all there are reasons stated for not carrying out this practice such as a quote from Steve Wozniak advocating working alone, not on a team.Also other reasons such as programmers being more likely to be introverts and therefore may not be suited to pair programming. Then there are the reasons as to why pair programming is such a good development practice. I agree in the main with this article and have a few additional points to support this, yet also have some opinions that differ from what is originally written.

Personal experience

Having completed the System Design Project in my third year here, I have experienced first hand working in a team and knowing how well pair programming worked for us. Everyone was working towards building a robot that could play football and this task required lots of collaboration. There were many different parts to the overall system such as vision, artificial intelligence and movement of the robot. Therefore a decision was made early on to use pair programming as much as possible as we felt this would greatly increase our speed of development. This was especially important as there were deadlines every few weeks that required new capabilities in the robot to gain credit overall.

There are two points in this article under the heading “We need a proof my dear Watson”, the first is “a huge percentage of bugs and defects can be caught before release” and also “there is a lot of knowledge sharing and project ownership involved in the process.” I found this to be true in both instances as there were bugs that were definitely caught and fixed quicker by working in pairs rather than one person working on it and testing it themselves. I also found out that when working by myself it is much harder to make progress as I felt I needed to communicate with another team member. Therefore I also found the second point about knowledge sharing also to be true. In the end our team performed well, with a good performance in the final tournament, so I think using pair programming helped contribute to that success.

Pair Programming 101, do you always need to follow the rules?

The author also discusses 5 important rules about pair programming. One of which is “Pairs should be formed flexibly and naturally, rather than by fixed assignment.” They also state that a strategy should be followed when matching pairs, suggesting matching people with similar skills first and then trying junior developer plus senior developer. I would argue that there is a benefit to having pairs formed by assignment in some cases as if for example joining a new company or a graduate scheme, it is common for the junior developer to be paired with a senior developer. This allows the junior developer to learn from someone who has the experience of working at the company for years and who has experience of technologies that the junior developer has not used before.

Another rule is “Collaborate with your partner, do not critique his work.” I agree with this as if you are all working towards the same goal as part of a team, you want to be getting on together not critiquing the other person’s work. I know personally from working on other projects that this can lead to arguments which doesn’t help in achieving the goal you are supposed to be working towards.

Also stated is “Always use a big monitor(or more) and two keyboards.” I agree in the use of multiple monitors, in the case of the System Design Project we weren’t able to do this, but from my own experience of programming outside of this I have found this to help me be more productive. However, I don’t feel that using two keyboards is necessary, in fact I have never heard of this being used anywhere, but multiple monitor set ups are used in many companies.


In the main pair programming is a great development practice, and I have found it to work personally. However, some rules don’t always need to be followed and others are maybe better to be broken, depending on the type of project that is being undertaken. Care should be taken in matching people into pairs to give the best benefit to both developers and also to help the project in the best way, not just chosen because two people get along with each other or their skill level is the same.