Deploying Pair Programming
Please match the horoscopes before pairing!
Pair progamming as an agile way to create software quickly with reduced time for testing or bug fixing, is gaining acceptance. In this note we discuss the process of pair programming and how it can help in reducing in-process errors. We discuss some results of pair programming that have been reported in literature. The note also highlights the soft aspects of pairing, which if not done keeping the individual capabilities and compatibities in sight can create a negative influence and project can be in jeopardy.
What is pair programming?
Two programmers working side-by-side, collaborate to create the same design, algorithm, code or test. One programmer, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects and also thinks strategically about the direction of the work. On demand, the two programmers can brainstorm any challenging problem. Because the two programmers periodically switch roles, they work together as equals to develop software
How to deploy Pair Programming?
The best way to pair program is to just sit side by side in front of the monitor. Slide the key board and mouse back and forth. One person types and thinks tactically about the method being created, while the other thinks strategically about how that method fits into the class. One may ask that all that is fine, but why it should be done at all, as we can afford more than one machine per programmer!
Why Pair Programming?
Let us assume that we need to develop a component that has five key methods or functions. In the single programmer scenario, the programmer will look at the detailed design description and start coding the functions one after another. Typically he/she may be thinking 2-3 lines ahead, while coding some simple lines. If the programmer gets stuck in a complex logic, he/she will try to wrestle with the problem in his/her mind. This can some times create highly involved logic or increase the coding duration for the component. Also because of the above reasons, the programmer may do mistakes in the syntax; logic or worse may not implement the needed functionality in the code.
A programmer when he gets a detailed design description of the component ideally should carry out planning regarding which of the functions he is going to take up first, what variables and data structures need to be described, what are the specific implementation requirements of each function, etc. Then he should start coding. However, in real life, planning and actual coding typically are amalgamated intricately and actually lead to time delays and are potential sources of errors in the output. Let us say the time durations required are as given in Table 1.
| Coding Activity | Duration (minutes) | Elapsed Time (minutes) |
| Comprehending detailed design | 120 | 120 |
| Plan F1 | 60 | 180 |
| Code F1 | 180 | 360 |
| Plan F2 | 15 | 375 |
| Code F2 | 45 | 420 |
| Plan F3 | 30 | 450 |
| Code F3 | 90 | 540 |
| Plan F4 | 15 | 555 |
| Code F4 | 45 | 600 |
| Plan F5 | 30 | 630 |
| Code F5 | 180 | 810 |
| Review | 120 | 930 |
Table 2 shows the same schedule with pair programming. As can be seen, we cut down the coding time by about 20%. One may however say that schedule compression with more effort (2x 750 = 1500 man-hours > 930 man-hours) is not a very good output. However, this may not be the true picture if we take care of the time taken to test and fix the bugs during testing phase. In fact, the output of pair programming will have less number of bugs and less effort will be spent in bug-fixing. Another benefit is that by pair programming the project creates two code-aware persons in the team, which in the current scenarios of high attritions, is a very useful benefit.
| Programmer | Coding Activity | Duration (min.) | Elapsed Time (min.) |
| P1 & P2 | Comprehending detailed design | 120 | 120 |
| P1 | Plan F1 | 60 | 60 |
| P2 | Plan F2 | 15 | |
| P2 | Plan F3 | 30 | |
| P1 | Code F1 | 180 | 240 |
| P2 | Code F2 | 45 | 285 |
| P2 | Code F3 | 90 | 375 |
| P1 | Plan F4 | 15 | |
| P2 | Plan F5 | 30 | 405 |
| P1 | Code F4 | 45 | 450 |
| P2 | Code F5 | 180 | 630 |
| P1 & P2 | Review | 120 | 750 |
Pair programming increases software quality without impacting time to deliver. It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality. With increased quality comes big savings later in the project
Programmers need to Collaborate – Cooperate to Elaborate
If the pair is able to combine the skills in a synergistic manner, it can amplify benefits in multiple dimensions for the project. If the discussions or the ad-hoc, non-formal brainstorming sessions are carried out in open, synergistic manner, leveraging the creative tension, the pair programmers can be an order of magnitude more effective.
However, there is, as always, the other side of the story also. I believe it is really important to take care of the personality’s resonance before plunging teams into pair programming.
Taking Care of the Pair Compatibility – The Other Side
Programmers who practiced Pair-programming, in experiments or in reported real life case studies have pointed out following main areas of concerns:
Egos – the members of homo-sapiens called programmers are found to be highly egoistic. Typically, they don’t have a strong affinity to create programs with others of the same breed. The amount of arguments in strong ego-duels between the pair programmers can not only nullify the benefits of pair-programming but in fact can actually create a permanent dent in the project fabric.
Speed/Skill Mismatch – If there are unbalanced speed or skill levels in the team, it can generate more negative than positives.
Fear of Incompetence – This is surprisingly an important factor. A programmer who doesn’t have enough skill may be learning on the job. This fact in a pair programming scenario will become known to the other person, which the first person may not like to disclose.
Programmers with confidence, modest ego, compatible skills and attitude to collaborate will help make the pair programming a success.
Patience and Tact – Pair programming takes a high percentage of patience, tact and a lot of social skills. This in effect means – maturity. It is a challenge for the manager to choose programmers who are mature enough to have patience, tact and social skills (Actually if one think these are the traits required for the project management job!).
Keeping an open mind and willingness to see other person’s point of view are some of the other traits came out of these studies.
What shall we do?
The increasing complexity of software in the new applications is creating extreme demands on software development teams. Counter intuitive methods such as pair programming definitely have shown a great value in balancing the conflicting demands of complexity, productivity and quality.
We advocate a step by step process of deploying pair programming in projects. The challenge really lies in communicating the benefits collaboration and remarkably reduced time needed for testing to the programmers. Second challenge is to choose one or two components earlier for developing them using pair programming. However, the biggest issue is to form the right pair, to show this as the success story for the rest of the project team.
In nutshell, please do explore experiment and deploy pair programming, but start by matching the horoscopes of the pair, and of course keep your fingers crossed!
References
No comments:
Post a Comment