Pair Programming
Background
I have been a follower of pair programming for a quite some time. Every time I try to advocate the use of pair programming I come across few faces who raise their eye brows (outside friends) 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 2005/2006 when I had attended a BDotNet user group meeting. There was a presentation by a person from ThoughtWorks (I guess). That point of time I thought it is a waste of time. But I actually experienced it personally from last 6 months or so for some of the complex task in few of the Respond sprints. I got to work closely with my counterparts in UK. 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.
How Developers Spend Their Time (Ref: PeopleWare)
30% = Working alone.
50% = Working with one other person. (We follw :-) )
20% = Working with two or more people.
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 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.
Important point is; 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 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 back-seat 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 case if the PO does not want to keep more stories in progress then you can follow this process. We can follow pair programming while developing a functionality or fixing complex issues.
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 times we practiced this.
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. While the development is in progress different people can pair up with this primary developer. 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 things 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.
Some special thoughts from me here...
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 my partners with whom I have pair programmed whenever an opportunity I got with. 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.
Keep Pair Programming....
I have been a follower of pair programming for a quite some time. Every time I try to advocate the use of pair programming I come across few faces who raise their eye brows (outside friends) 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 2005/2006 when I had attended a BDotNet user group meeting. There was a presentation by a person from ThoughtWorks (I guess). That point of time I thought it is a waste of time. But I actually experienced it personally from last 6 months or so for some of the complex task in few of the Respond sprints. I got to work closely with my counterparts in UK. 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.
How Developers Spend Their Time (Ref: PeopleWare)
30% = Working alone.
50% = Working with one other person. (We follw :-) )
20% = Working with two or more people.
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 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.
Important point is; 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 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 back-seat 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 case if the PO does not want to keep more stories in progress then you can follow this process. We can follow pair programming while developing a functionality or fixing complex issues.
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 times we practiced this.
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. While the development is in progress different people can pair up with this primary developer. 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 things 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.
Some special thoughts from me here...
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 my partners with whom I have pair programmed whenever an opportunity I got with. 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.
Keep Pair Programming....
Comments