Background
I have been a follower, admirer and advocate of pair programming for a long time. Every time I try to advocate the use of pair programming I come across few faces who raise their eye brows and I get an impression that they are thinking what a waste of time. But I believe that if you use pair programming judiciously it can be a great asset. Lets see why I tend to lean heavily in favor of pair programming.
Does pair programming really work
I came across pair programming as a term way back in 2002 or 2003 when I had attended a BDotNet user group meeting. There was a presentation by a person from ThoughtWorks. But it was not until late 2007 and early 2008 that I actually experienced it personally. While I was working with my previous employer, after joining they had sent me to UK to understand the Agile practices and to get familiarize with the team. I got to work closely with my counterparts in UK and learn new tools and technology while pairing up with them. Ever since then I have been a big time follower of pair programming.
It is a proven fact that two brains working on a problem are far better than individual attacking the same problem. It brings different perspectives to address the same problem. People are able to generate ideas by discussing different approaches. There is also the advantage that you need not have a separate code review because it automatically gets reviewed. There is also a shared understanding between two or more individuals related to the same piece of code. In an unfortunate event of bugs arising out of that piece of code potentially there are two people who can address it. This reduces the dependencies on individuals and serves the Agile principle of cross functional teams. Pair programming can help new members of the team learn the tricks of the trade much faster. The system and the domain knowledge can be shared much faster by pairing with experienced developers.
Imagine a situation where a senior member has very good systems and domain knowledge but is not very well versed with latest technology. Whereas a new team member is very good at technology. If these two individuals pair up they can complete the tasks much more faster compared to both of them doing it individually. In another situation two developers from different expertise can contribute to help each others expertise. like a database developer and a middle tier developer working together can improve the delivery of code.
Pair programming reduces the need for specialists in the teams. You can have people who know little bit of every technology and tool used within the project. Another advantage of this I see is that it helps people in moving across teams much more easier. You no longer have hardcore dependencies on one or two individuals. In an unfortunate event of somebody leaving the organization or contractor leaving after the contract period you no longer have people taking important knowledge with them. You also don’t need the so called knowledge transfer sessions or handover between different people. My personal experience says that these sessions are useless. The person giving the knowledge is more or less looking at finishing the session and moving on as quickly as possible while the person trying to acquire the knowledge might not have enough information of what is required.
One of my ex-colleague made a very important point regarding pair programming. He said when you pair with someone for any reason both the individuals have to benefit from it. There is no point in pairing just for the sake of it. If only one person in the pair keeps on working at the task and the other one just sits besides him then it doesn’t serve any purpose. That is why the ping pong or shifting the keyboards every now and then between both pairs is essential. It keeps both the people focused.
Many people turn down the suggestion to pair with others saying it reduces productivity. My personal experience says that it improves productivity. One thing I have experienced quite often is that while working individually you tend to get distracted a lot by a new email popping up in your mail box, a new text message alert appearing on the cell phone, a phone call or some one gossiping around your workstation. While you are pairing with some one these things can take a backseat you tend to concentrate a lot better.
There is a general feeling in Agile community that most of the production code has to written by a pair. I do believe that there is lot of value in doing so as it improves the quality of code by manifolds. But there can be situations where a particular team has been working on the same project for quite sometime, almost all members have sound domain and technical knowledge and there is very little benefit gained by pairing with other team members. in such scenario you can skip pair programming and revert to it only when a complex functionality is being developed.
In my previous project one of my colleague had suggested that any live issues or production bugs needs to be worked by a pair. I see a lot of value in doing that. If for whatever reason you were unable to do pair programming while developing a functionality, at least while fixing a production issue you can have more than one person trying to address it.
Along with improving the technical and functional skills, pairing also helps in improving the interpersonal skills. You can get the team to gel together. The communication improves drastically as a result of pairing. You don’t need lengthy emails and separate approvals for getting small routine things done. I have seen couple of teams who practiced pair programming work very well as a close knit unit.
Conclusion
I firmly believe that pair programming is a must when the team has got different levels of skillsets. As the gap decreases the amount of pairing can be reduced. Another technique which helps a lot is to swap pairs periodically. Instead of same people pairing up for long duration there can be a primary developer responsible for delivering a user story or a piece of functionality. While the development is in progress different people can pair up with this primary developer. The frequency can be anything like swap pairs daily or twice during the day or at a logical point. Lets say the story has UI to be implemented, service layer changes to be done, data access to be modified and database schema changes. All these changes can be performed by a primary developer and swapped at each point with a different partner. I hope you can realize the benefits of taking such an approach. To me pair programming is very fundamental to Agile and one of the most required tool for building a truly cross functional team. If some one says they are working on Agile and they have specialists in one area in their team I am afraid they are not truly Agile.
Pairing may not be limited just to developers itself. In a truly cross functional team you can have a developer and business analyst pairing together. You can have a business analyst and a a tester pairing together. You can have a developer and a tester pairing together. The possibilities are many. If you can collaborate among all these different aspects of software development you can very well imagine the overall impact on the quality of what is being developed and delivered to the customer.
I have experience the benefits of pair programming and would suggest people to try it out. I have learnt a lot from seniors and juniors with whom I have pair programmed whenever an opportunity presented itself. instead of reading 100 pages of book and understanding very little from it, it can be very helpful to spend 10 minutes with an experienced developer and get to learn most of it. I would like to hear about your experiences. In my personal experience pair programming really works.
Until next time Happy Programming 
Great article sirji.. very much true !!!
ReplyDelete