As professional programmers, our goal is to produce high quality software for our customers. Pair programming is a helpful technic that allow to reach this goal.
Developers do pair programming when they sit in front of the same computer to complete tasks for a new user story. To me it is a different job than pair debugging, where you work on existing code in order to fix it, in pair programming you create new functionalities for your application.
At first it can be seen as a waste of time since two team members work on the same machine and it might look that the capacity for these programmers is divided by two.
I do not share this opinion, to me pair programming is a very good way to improve efficiency when working on a new feature.
Staying focused
When you are two it is likely than there will be always one of the two developers that knows what should be done next. It is helpful when one in the pair starts to feel a bit tired, the other one can continue and you rotate regularly. This will prevent any loss of total focus during the development phase, but the pair should still do some breaks from time to time.
When one of the programmer is coding the other one looks at the written code and can detect mistakes early on, it is an effective live debugging technic.
Share knowledge
When a pair of programmers works on the same user story together they will share the knowledge of the implementation. They will both know how it has been developed, this way your team is no longer dependant on a single developer for knowledge of a specific feature.
Beside technical knowledge you can also gain a better understanding of the business knowledge related to the user story you are working on. For instance instead of having a developer working on the front office workflow (from a business perspective) and the other one on the back office one, both developers can pair-program on the two subjects to understand how the system should behave on the front side and on the back side.
The code is also written by several persons and therefore there is no code ownership, this will avoid situation like “do not touch my code!” or “I won’t touch code”. The code is owned by at least the two programmers forming the pair, a step toward egoless programming.
Share skills
Pair programming sessions are also good to learn new practices, tips and tricks. When working in pair you can simply discover a new shortcut for your favorite IDE you were not aware of.
And most of all pair programming can help you discover new skills and practice them. For example you can improve your Test Driven Development (TDD) technic when working with a pair that is more experienced than you are. During a pair-programming session, we (my teammate and I) developed an entire topic using TDD, one wrote a failing test and the other one had to make it pass and then write a failing test and so on. This was a very rewarding experience, we were both new to this yet we practiced together and improved our knowledge.
Pair-programming is a social activity, it takes time to learn and can be frustrated from time to time. Yet it is very helpful to share knowledge amongst your team, you can always learn something new from one of your peer.
This practice can seem like a waste of time but since the pair is always focused on the topic, it can go faster with a higher level of quality. You can find a study about costs and benefits of pair-programming here.
See you next time!
Coding Journeyman 
Hi Julien,
Yes I agree with you. We need an open minded management who can accept this pair programming model. I guess companies that are lead by the younger generations would be more open minded. Thanks for the advise.
LikeLike
How do you justify the benefit of pair programming to the management? Have you had any experience with it?
LikeLike
Hello Joshua,
Thank you for your interest. Your question is definitely a good one and a tough one.
I had not experience this situation myself but I will explain what I would do in this situation.
One of the benefit of pair programming is the fact that the knowledge is shared, so your team is less and less dependant on a member for a specific topic. It is also a good way to teach newcomers about the system for both technical aspects and business ones.
Of course learning how to pair program takes time and has to be seen as an investment and not a cost. For this the team has to be in a learning phase.
And there still is the paper of Alistair Cockburn about costs and benefits of pair programming.
I hope this information will help you!
LikeLike
Hi,
I do not object the idea of pair programming. The challenge is management want to see immediate impact from pair programming. Sometimes it is really hard to justify. I think most papers are qualitative measurement which doesn’t really get management buy-in. Let me know if you are able to convince the management about pair programming.
LikeLike
Hi Joshua,
To be honest, I don’t think you can see immediate impacts, it takes time. This is the difficult part when we want to introduce new “good practices” in our workplaces.
To convince the management you can ask for a period of time during which you are allowed to use the new practices. And at the end of this period you can provide data to the management to let them compare the work done with new practices to the work done without them.
If you can not even get this kind of deal, you can accept it or you can look for a place where the management is more open minded.
This is just my opinion and what I would do in a situation like this.
I hope it can help you.
LikeLike