Recently I got the chance to try out the power of pair programming, and I thought I’d share my thoughts from the experiment as tips for aspiring pair programmers.
It was in fact only after the experiment, while writing this piece, when I went and looked up what was usually meant by pair programming. Funnily enough, what we did was pretty much spot on with the definition and methods, which would suggest pair programming is something very natural to grasp and simple to utilize without pre-existing knowledge or experience. Much of the success we had I would definitely attribute to the chemistry between me and my partner: it is vital that the pair is on similar wavelengths. They can produce different type of code – heck, that might even be a good thing – but they should be able to communicate their ideas effectively.
So what’s different? Vocality. You cannot keep your thoughts to yourself anymore, you have to speak them out. You have to process the code verbally, and in a fashion understood by your pair. Sometimes you will talk first and code after, sometimes it is easier to first show the code and then explain it. Just don’t code a complete class or method and then try to explain it for ten minutes, because input from the both of you is the key to the victory here.
Roles are important. Personally I would suggest it cannot be a 50–50 % job. Occasionally opinions just tend to clash, and you’ll quickly get stuck on arguing about minor details. The one who is driving the show should always have the final word. Ideally, this will ensure it is the idea that is the best, not by the louder person that gets implemented.
What are the benefits? Both individuals will understand the code better because they have to be able to explain it to someone else. The code will be less prone to errors because there are two pairs of eyes keeping a close watch on things at all times. The resulting solutions are likely to be more easily understood by whoever next works with the code because it has been engineered by and for two different minds from the start. Likely they are also more elegant since they represent the joined skills of the pair.
One of the absolute biggest gains and best applications for pair programming is if two people with varying information of the underlying system team up to tackle issues from their individual areas of knowledge. In addition to generating new quality code, both programmers get to learn the details from each other. Soon the whole team knows every nook and cranny of the system and business is secured against unexpected personnel changes. This makes a good selling argument for management, I should think.
What is pair programming good for? I personally haven’t had the chance to apply it in different types of projects, so I don’t speak with much in-depth knowledge. What I can deduce from our experiences, however, is that it is best suited for projects where one of the goals is to teach the underlying system quickly to everyone in the team. The participants must naturally be open and recipient to the idea otherwise it might be painfully ineffective.
Are there any cons? Sure. Exactly because it’s all about the pair’s combined effort, it also places a mental toll on the individuals. They have to be alert a hundred per cent of the time and operate out of their own comfort zone. They have to work in sync as a unit that stops every time one of the pair grinds to a halt, which can temporarily break either one’s thought process or focus. Having said that, I’d say the benefits outweigh the faults when pair programming is administered in moderation.
This was by no means a comprehensive study into pair programming, but I’m hoping it’ll be useful to teams who either have yet to try it, or have problems executing it. Peace and love, may your code prosper.
About the Author
|Tsuri Kamppuri (Twitter)
Tsuri is a bachelor student of Media Engineering. While not toying around with bleeding edge tools in web development and gulping down copious amounts of energy drinks, he indulges in occasional trips to snowy forests with a board under his feet.