Agile - Pair Programming - what, why, when, how and few objections against this practice

Pair programming:

When I heard there is something called “pair programming” 8 yrs. back when I joined an Agile team, I was fascinated. I was like “WOW”…what is that? I was swayed away by open atmosphere created in our team, and moreover perhaps I was more of relieved to know that my peer would review the code when I would be coding! Errors made by me would be immediately caught and would be rectified. Since this would be collaborative effort, everyone would be responsible for the code quality and I hoped to get hands-on guidance/training from my seniors in the team as well.

What is pair programming?

Pair programming is something where two programmers are engaged in coding, one being driver (actively writing the code), other being navigator (reviewer). They can switch the role periodically.

The navigator is expected to review the code when the driver is coding. Normally navigator gives the strategic direction on code, after having an open and honest discussion with her partner. Concept of user stories and pair programming shift the focus from regular waterfall documentation to discussion. Of course, we have to be engaged with effective and to the-point discussion.

When can you contribute to a discussion? – Yes, you are right, when you are a good conversationalist. As Dale Carnegie said, “to become a good conversationalist, you have to be an attentive listener”.  Ask good questions. Give honest input.

My experience is, pair programming is more effective and produce best result when both programmers are matured, good listeners and both believe on collective ownership of code. Pair programming can be a wonderful learning experience for both the programmers if both of them add value to code, if both of them are engaged with fresh thinking that is aligned with the story they are working on.

Driver and navigator generally have useful and effective conversation on, for example,

1.        improve code quality

2.        if a class/function(s)/module needs to be re-factored. If yes, they can discuss on effective way of re-factoring the code on-spot before proceeding to further coding.

3.        code coverage/statement coverage. If the agile team is following TDD (Test Driven Development), the pair programmers are normally concerned about the code coverage.

4.        they can decide to concentrate more on complex area of a class/function/module.

5.        spike/brainstorm on some issue

Why pair programming?

Probable answers are:

1.        Fundamental intention being code-review happens sooner and as a result; this gives wonderful chance to rectify the code sooner than the total time aggregated by series of process activities like - code-build goes to tester, tester finds a requirement gap (for example), raises defect, defect is picked up by developer, developer discusses with peers/HLD owner and then resolves it.

2.        Pair programming facilitates the knowledge transfer. This is an ideal way to bring new developers up to speed on the application.

3.        If in case, pair programming is genuinely not possible 100%, then team can gauge over most difficult area in the code or most sensitive module of the code. XP coach or SCRUM master can determine the stories that really require pair programming. Identify stories that may not be independent, i.e. code depends on other code module. Identify some stories that may not be clear from requirement point of view, OR some portion of the code seem like non-testable – those cases, pair programming is supposed be effective.

4.        XP coach or SCRUM master takes care of another aspect of pair programming, which is move people around.

         This helps the idea of “team” feeling, “collective ownership”, cross functional team. Members of a pair can break once a task is complete and pair with other member.

How pair-program?

Pair program, as the name suggests, two people working on a task on a single computer.

The best way to pair program is through co-location, sitting side by side in front of the monitor. Slide the key board and mouse back and forth. Both programmers concentrate on the code being written.

However, I observed an issue with this style of pair-programming set up. The navigator, if he has an input and wants to modify the code, he sometimes “hover over” the keyboard when the key board is with the driver. The best way I experienced was, having single monitor but a pair of keyboards and a pair of mouse, each device with each programmer of a pair.

Objections:

Sometimes, management discourages pair programming.

 Objections/concerns are raised from management point of view.

1.        “Pair programming is expensive. Why shall I pay two programmers for a job that can be done by one person?”

-Pair programming will cost more in short term. However, that additional initial cost will very likely be paid back with shorter schedules and with higher quality. That means lower maintenance cost. Since discussions and code-review get done at the same time of coding, there is less chance of missing a requirement, less chance of affecting an already existing functionality with your new code. This can be reinforced again by automated regression testing, I shall touch upon later.

Mike Cohn advises “Pair on the most difficult modules and see if they have fewer defects and are easier to maintain later, perhaps in comparison to similar modules from other programs done without pair programming.”

2.        During my initial days of exercising pair programming when I was in an Agile team (eXtreme Programming), I myself thought –“why the XP coach is deploying two resources to do one task. We are in hurry.”

-I asked her one day shading all my inhibitions. She was calm and replied “this is the time- we need pair programming the most”. Gradually I experienced, pairing leads to shorter project duration since fewer hours passed on the clock (it may take more person hours). High-visible projects are always under financial pressure. However, the comforting fact is- the overriding concerns are not so much person-hours as time to market. After all, everyone’s aim is to get the product faster in the market.

At last, ideally pair programming is not a mentoring program. There is not teacher-student relationship. The pair programmers are co-programmers, they are peers.