Pair-Programing Explained

Pair-programming is an agile practice in which two developers are working together, at one computer on the same task. The two developers are often interchanging the roles in this practice – the driver and the navigator. The driver is the one who is actively working on the task, doing the concrete implementation of the code, while the navigator is observing the work, trying to identify flaws, think about the overall design, in which the code developed fits.

There are some obvious benefits from this practice. It is clear that you get a better code: code is written and reviewed at the same time, corrections/improvements are implemented on the spot, design is simpler, and as result the code has less defects and is more maintainable. Also, another benefit is you get shared knowledge throughout a team (there are at least two persons that knows about each piece of code). And since the pairs are changing quite often, each developer gets to know at the end the whole application. While programming you are also learning: developers are constantly changing ideas, discussing solutions, sharing technical knowledge.

Not so obvious benefits of this practice are related to higher productivity and better time management. Using two resources for a task of one looks like wasting resources (time and effort). It is a bit counter-intuitive but due the quality of the results, on a longer term the return of investment is greater: better code means less costs for maintenance, and maintenance is usually very costly. Knowledge shared means that any other developer can be involved in solving any issue without additional costs of training and learning.

How is productivity higher? Working in pairs, is far more intense; it keeps you constantly focused to what you are doing, and less exposed to interruptions. You are progressing faster in the task with greater quality. Pair programming reinforces some programming habits that are tend to be put aside when working alone: continuous testing, design refinement, code reviews, all these take a lot of self-discipline. Working in pairs, you are sensing a positive pressure to perform all these tasks.

Everything looks great so why not used all the time? Like everything in the world, 100% from something is never a good thing. Pair-programming success highly depends on the people personality and their level of skills, and of course cannot be done without co-location (which is these days is no longer a must when organizing development teams, everybody can work remote). People who do not like each other, or have problems in communication or they are not at comparable levels in their skills will not pair and all the above benefits will become losses.

Another important thing is that sometimes people are more creative alone. While brainstorming on ideas is important, developers tends to form their ideas alone and put them in discussion; hardly they are just starting to think on a solution together without a previous thinking on their own. So, alternate periods of pairing with working alone.

Pair programming is not a silver bullet; takes a lot of discipline to apply it and also is highly dependable on how people are, their personalities.

It can be used inside projects that are done in classical way, with individual tasks, on specific topics like: working on a highly critical component, or sharing the knowledge about a certain component in order to get better support (if one developer is not available, other can easily take its place and solve the problem).

Switch pairs often (even several times per day), work in pairs on small clearly-defined tasks, take small, frequent design steps (apply test-driven development for example) discuss about your assumptions, your short-term goals, but also about project overall. And ask questions if you are confused. Even asking a question or explaining something you did not understood might make you see the answers, before your partner responds.