Having worked with different agile methodologies I have frequently met people completely skeptical to the fact that two people sharing a computer can be as productive (or more) than if they were separated. That led me to write this article about pair programming and I hope that you enjoy it.
As an agile evangelist and pair programming admirer, I'm going to go through a few major topics on this subject and share my own personal experience. This post does not intend to teach you how to do pair programming, instead it will show you some benefits that would lead you to try this approach. Please leave your comments if you want to share your point of view on these matters.
As an agile evangelist and pair programming admirer, I'm going to go through a few major topics on this subject and share my own personal experience. This post does not intend to teach you how to do pair programming, instead it will show you some benefits that would lead you to try this approach. Please leave your comments if you want to share your point of view on these matters.
Knowledge transfer is in my opinion the most important benefit of pair programming. Teams that practice pair programming have a consistent knowledge base distributed among its members, so that code produced by any member of the team tends to have the same pattern everywhere. You won't have to spend resources on team training because the daily developing activities become the training themselves. I cannot overemphasize how important it is that the senior members of the team be reminded of that. Some people just weren't made to be good teachers or even don't like to share knowledge. These people just won't fit to pair programming and are likely to be a lot more productive by using the single programmer approach. Furthermore new technologies are always popping out of nowhere and external training should not be neglected.
The second most important benefit would be quality. A pair will always have a person that controls the keyboard at a time. This person should focus on the coding, analyzing, syntax, tools and the action of developing. The name given to that person is "pilot" as he will be the one getting his hands dirty. The other person will be watching the development, but he's got no less responsibility. The "co-pilot" as we call it, must provide support in many ways in order to allow the "pilot" to focus on the coding activity itself. The "co-pilot" tasks involve checking the code for bugs, proposing different architectural approaches, executing parallel tasks and foreseeing possible impacts of the development being made. That said, the quality of the code is greatly improved by the pairing, reducing the likeness of code being re-worked to fix bugs, thus accelerating development. It's important to mention that a pair must always switch positions between "pilot" and "co-pilot".
Skill
Considering the skills of your resources when pairing developers is not only important, it's essential. Different combinations lead to different results and some of them can prove to be a total disaster. I've suggested a few combinations here, but it's unreal to divide developers as novices, average and experts. The combinations are in truth a lot more complex than that as developers tend to have specialties and expertise that differ a lot one from another. Even so I'm providing a few suggestions for you to grab the concept of comparing combinations:
Novice + Novice: Weak combination not promising in terms of results. Two unseasoned developers together tend to produce results slowly and with bad quality. Worst, it's not likely they will be teaching much to each other. The only profit I usually saw from doing this was that it is a great way to analise the developers profile. While some will try to learn and struggle to complete a task, some will just bug people around and try to copy things, or fake some workaround. It's also a good way to determine which of the pair is fitter for decision making and leading.
Novice + Expert: Also not very promising, expert programmers are usually very fast and have little patience and little time to be teaching the basics. The results will be produced very quickly and with quality, as the novice won't have anything to add or debate about what's being coded. In many ways, it's pretty much the same as having the expert to code by himself. Only use this combination if you have a spare novice that you don't have anywhere else to put nor any task to provide.
Novice + Average or Average + Expert: Usually a great combination, we will have a productive pair with good debating and questioning. The most experienced member will spend some time explaining questions on technologies, but in the end you will probably have the tasks done timely, while training the resources of your team.
Average + Average: Good pair. Whenever two programmers with a similar average level of skill are put together they will strive to get the task done quickly. They might stumble on a couple of technical complexities, but being a pair they will have an easier time by putting their efforts together to achieve a common goal. The danger here is to have on programmer coding and the other just watching. As mentioned above, to have a good co-pilot is essential if you want to have a lower re-work rate and fewer bugs in your end software.
Expert + Expert: Rarely a good idea. Except on architectural decisions, experts don't really need to rely on a co-pilot. Don't get me wrong, I always think that the more, the merrier, but usually having two experts coding together does not justify the investment as these tend to be scarce resources. Coding is easy for them and the best idea would be having experts to make big decisions in a meeting.
Duration
It's also important to take in consideration the duration of each pairing. It could be a single day session or several iterations, but usually having a pair to work together for 2-4 weeks works well. Less time than that and the members won't have time enough to synchronize their work rhythm. More time than that and differences might begin to bother the pairs. Also, having your team to switch partners regularly will improve the community feeling. Developers learn their strengths and weaknesses and that is really crucial for keeping the team calm and steady for some tight scheduled or complicated projects.
Communication
Communication is the key for good results with pair programming. It must be constant between the pair and also with the team. It must be productive and have constructive criticism. Not anyone can stand being criticized and questioned during development and that's fair. Pair programming is not intended to anyone. There are personal traits that a developer must have in order to be a good pair programmer, and that includes patience and people skill.
Discipline
People developing in pairs are constantly being supervised and watched. By their own partners it is. They tend to focus on the work and lose a lot less time with personal stuff. They won't be likely to stop a good programming rally just to check their email or chat with someone. Much less to be watching the newest review of some crazy gadget. That greatly increases productivity, at the cost of stressing the developer. Different people will react differently, but in the end, some intervals should be allowed after long programming sessions to allow the developers to have some privacy. Having to share a computer does not mean that they don't need a private workstation, or have to be together at all times. What worked fine in my previous experiences was to extend the lunch time, allowing the developers to have an extra free time after lunch to take care of personal stuff.
Another complicated situation happens when the team must study a new technology or learn to use an entirely new API. When there's nobody to share the knowledge on a topic, pair programming should NOT be used at all. Having pairs to study the same subject together is very much like de Novice + Novice approach mentioned above, with all of its drawbacks.
Conclusion
Yes, pair programming can be as productive or more than single person programming. I've seen it myself on different teams and on different projects. The speed of having separated developers is counterbalanced by better quality code that doesn't have to be re-written and developers that focus on their work instead of YouTube, Facebook and other crap. The reader must understand that it does not mean that it always will be better. There any many cases where pair programming will suck and will just waste one of your resources. My final thoughts? Use a hybrid approach. Using both pair programming and single person programming will work just fine if the team leader and the developers know on which stories should be tackled in pairs or not.
Discipline
People developing in pairs are constantly being supervised and watched. By their own partners it is. They tend to focus on the work and lose a lot less time with personal stuff. They won't be likely to stop a good programming rally just to check their email or chat with someone. Much less to be watching the newest review of some crazy gadget. That greatly increases productivity, at the cost of stressing the developer. Different people will react differently, but in the end, some intervals should be allowed after long programming sessions to allow the developers to have some privacy. Having to share a computer does not mean that they don't need a private workstation, or have to be together at all times. What worked fine in my previous experiences was to extend the lunch time, allowing the developers to have an extra free time after lunch to take care of personal stuff.
Another complicated situation happens when the team must study a new technology or learn to use an entirely new API. When there's nobody to share the knowledge on a topic, pair programming should NOT be used at all. Having pairs to study the same subject together is very much like de Novice + Novice approach mentioned above, with all of its drawbacks.
Conclusion
Yes, pair programming can be as productive or more than single person programming. I've seen it myself on different teams and on different projects. The speed of having separated developers is counterbalanced by better quality code that doesn't have to be re-written and developers that focus on their work instead of YouTube, Facebook and other crap. The reader must understand that it does not mean that it always will be better. There any many cases where pair programming will suck and will just waste one of your resources. My final thoughts? Use a hybrid approach. Using both pair programming and single person programming will work just fine if the team leader and the developers know on which stories should be tackled in pairs or not.
