Pair Programming

In any big project, the people in that project would be having different skills at different levels. The skill set can be different in design, coding, performance optimization, or the knowledge of the existing functionality, code base, coming up with scenarios etc.

When the developers are working independently, if they don't have all the skills, then the feature may not be complete in all the areas. They may implement the functionality, but, it may not scale, or, they may come up with good design, but, misses many scenarios. In those cases, typically what happens is, two ore more developers would be working on the feature one after another. After the first developer implements with the skills that they have, second developer takes over and fixes the issues. If one developer implements the functionality without any performance, second developer may optimize that for performance. If one implements with good design and provides good framework, another one may add all the scenarios. In most of these cases, the second developer would be re-writing what the first one had written. After re-writing, the first one would review it, to make sure, they did not lose anything in re-writing.

If both the developers sit together and implement the functionality, then it would take less time than both implementing individually, one after another. When they do it together, they would be covering all aspects first time itself, and it would save significant time.

Pair programming does not work well, if one is having very good skills in all areas when compared to the other. In that case, it would become like, one dictating the code and the other typing, or one typing and other just watching. It works very well, when both have skills in different areas or almost equal skills in all areas.

I have seen re-writing of the code by different people many times in the name of review, bug fixes or improving performance. Many times, it could have been avoided, if they had thought about the solution together.

Eventhough, Pair Programming is a good practice in general, it is not followed by many. When two people work together, the immediate question that is asked by many people is, why cannot one person work on that? It is difficult to answer, because, it is very difficult to tell something like, "I don't know ABC's of the existing functionality, and the other developer does not have good design skills". It is almost impossible to tell this to the manager. If the developers are of opposite sex, then they may face different issues.

Pair programming may miserably fail, if the programmers do not have good relationship or their thinking is not in sync. Of course, if the programmers do not have good relationship, not only pair programming, but, even normal development also would be effected. The following is a snippet from an article in yourstory.

If you have two lead architects designing a system, you’re likely to end up with a two-module project. This phenomenon was first observed in the 1970s, when compiler design teams with 4 lead engineers ended up with 4-pass compilers. If your team had only 3 lead engineers, they were likely to design a 3-pass compiler. The design of the interfaces between the modules is also likely to be heavily influenced by the relationship between the lead programmers. If your system has 2 architects that are good friends, you’re likely to end up with a two well defined modules with clean interfaces and detailed contracts. If the two are not very good friends, they’re likely to come up with a design that relies too heavily on standard interfaces (like XML/WebServices) that may ultimately not be flexible enough for the system.