There s a Study That Proves My Point

There s a Study That Proves My Point!

Proponents of pair programming often describe the body of evidence that surrounds pair programming s touted benefits. The most commonly cited study ^[6] was carried out by Laurie Williams, who also happens to be the coauthor of Pair Programming Illuminated and a contributor to PairProgramming.com ( http://pairprogramming.com ). The study is also described (and referred to repeatedly) in Pair Programming Illuminated .

The basic finding behind the study is that pair programming increases code quality by 15% but takes on average 15% longer. The conclusion then is that in exchange for a small drop in productivity, code quality is increased, which in turn saves time and money in later stages of the project.

The problem with this particular study, apart from the fact that it wasn t an independently run test, is that it was conducted in a university, using students rather than experienced professional programmers. Thus, the study is really only an examination of novice-novice pairing, which is actually the most unlikely and least desirable of combinations (we discuss programmer pairing combinations later in this chapter).

The pair programmers performance was compared with the performance of some solo programmers who also were students (therefore also novices). This raises the issue that the comparison wasn t a fair one. In a real project, solo programmers don t really code alone; they re part of a team. Typically, designs are reviewed by senior engineers who sign off on them, prototypes are written quickly to get the design right before the production version is attempted, team leaders monitor their team closely (particularly the novice programmers), and so on. All these practices help to increase both productivity and code quality, yet none was taken into account.

The result is that Williams study is academic at best; it isn t a true comparison-of pair programming versus software development in the real world. And yet, as we mentioned, it s the most commonly cited proof that pair programming works.

In the next Voice of eXPerience sidebar we get one programmer s perspective, straight from the source.

VoXP
Voice of eXPerience: Pair Programming Social Dynamics

by Rich Camden

As in other VoXP segments, the reality of what happens to an XP team is often quite different from what XP preaches in theory. For example, XP recommends that the coach also pair programs (i.e., the coach doesn t get special privileges above the rest of the team). However, this description from Rich Camden is a good example of what can happen to an XP project when the human factor also plays a part.

The story you re about to read is true. Only the name of the author has been changed to protect the innocent.

Pair programming is the worst of the XP tenets. To recommend pair programming across the board for all developers involved in XP is to not understand the people/personality side of programming. Yes, there are those who will benefit from having another programmer constantly assisting and reviewing their work. But there are many more who will feel uncomfortable and restrained with another programmer watching everything they do.

Unfortunately, this tenet above all others tends to dampen creativity in XP. Many of the best programming gems come after you absorb yourself in a problem and do much deep thinking. This doesn t occur when you have another programmer sitting at the same keyboard.

The strangest part of XP for me is the social dynamics that occur as a result of making many people do things that feel unnatural or make them uncomfortable. In my experience, XP was a mandate from management, not a grassroots developer movement. In a rather short period of time, projects were shifted from comfortable cubicles to small rooms packed with workstations, tables, and people. It looks a lot like a call center, with developers shoulder to shoulder.

I joined my team after the change to XP had occurred. When I first joined the team, I was most interested in pairing and how it worked in real life. I read comments and articles on pairing at PairProgramming.com and at the C2 Wiki pages to prepare myself . I wasn t entirely negative to the idea. Unfortunately, what I read didn t prepare me for what was in store for me.

Joining the Team

On my first day of joining the team, I imagined that an enthusiastic XP developer would volunteer to pair with me and show me the ropes . It seemed that one of the team leads or coaches would be the best person. Instead, I was asked to simply watch the team and get my workstation prepared for development.

As I watched the team, I quickly realized that nobody was enthusiastic about pairing, including the team leads. During the stand-up meeting, developers were asked with whom they were going to pair. Now it seems quite impossible that they would know this until they could surmise who wasn t busy and then ask them to pair. Thus, in most cases the coach would assign pairs. I can t claim to know what people were thinking, but the looks on their faces didn t seem to say, Oh, boy, I get to pair with ___ today!

Right of Association

I watched each developer closely to understand the dynamics of the team I was joining. There were two team leads: the coach and the person acting as the customer representative. The coach never paired. This seemed to set the precedent that pairing was indeed undesirable, and if you were lucky enough to be a coach, you didn t have to do it. The second team lead was actively developing but rarely paired either. Again, this seemed to enforce the idea that if you had seniority and were doing important work, you didn t need to pair. This doesn t surprise me at all. Nobody wants someone looking over his shoulder day in and day out. What amazed me, however, was that the same people were actively encouraging the team to pair in classic do as I say, not as I do fashion.

That s not to say there was no pairing at all. When assigned a pair, developers would act in good faith and perform their job. The developers that I witnessed pairing normally had a buddy that they tended to prefer to pair with. Again, I wasn t surprised. People associate more with people they work well with.

The ability to choose associates (the right of association) is one of the keys to success. Any successful person uses this fact to her advantage. Forced association only ends in frustration and mediocrity . But even pairing buddies weren t actively engaged in pairing as described at PairProgramming.com . What tends to evolve is an arrangement where the two developers agree to work together to beat the system. Essentially, the unspoken agreement goes like this: I ll work for a while and you daydream, then tomorrow you can type and I ll daydream.

Another interesting anomaly I noticed was that my pairs would always control-the keyboard. Never in 5 months did it happen that my pair volunteered to have me type. Of course, if I asserted myself, they would allow me to type, but never did one choose to watch rather than type. The unwritten understanding I gathered was that typing is preferable to watching.

Pairing Fluidity Explained

The partner preferences didn t go unnoticed by the team coaches. As any XP enthusiast will tell you, this is undesirable. A surefire way to solve this would be for each coach to pair with a different person from time to time. Instead, the coaches would break up pairing buddies and assign them using criteria known only to them. This drove me to consider what would cause team members to avoid the fluid pairs approved by XP.

The key to understanding pairing culture is the XP task card. If you aren t familiar with XP, task cards describe small tasks that make up larger project goals driven by user stories. A task card has a completion estimate usually between 2 and 8 hours. Once they ve finished a task, developers complete the card by writing down who completed the task and how long it took.

It s easy to see that the cards are basically a fine-grained record of exactly what transpires on a project. It takes software development and turns it into a textbook case of micromanagement techniques. Your objective is then to complete as many cards as possible with your name on them. This trumps the more productive desire to see the project succeed.

Your choices are then to either partner with someone you trust as a good developer or attempt to finish tasks individually. As you ve already seen, this natural desire to partner is discouraged in XP. Thus, you re at a disadvantage if you re paired with an undesirable partner.

Who would make an undesirable partner? Someone new to the project would definitely slow you down. Every single module would require some explanation, not to mention a description of the business processes behind the application. This explained why my teammates were so reluctant to show me the ropes when I d just joined the project. They d most likely have to spend most of their time explaining the whys and hows of what they were doing, unless we had an unwritten pairing agreement, which only happens after some rapport has been built up over time.

It also explains the lack of fluidity in pairs. There s no advantage or benefit to the individual besides deflecting the constant berating of your coach that you should pair more often (which begs the question, if pairing is so great, why don t they do it too?). It s a classic catch-22. You re damned if you do and damned if you don t.

A Metaphor for Molecular Expansion

XP enthusiasts love metaphors. I find pairing to be a great metaphor for the physical characteristics of air molecules. Boyle s Law states: If the temperature remains constant, the volume of a given mass of gas is inversely proportional to the absolute pressure. For most of us, that s pretty clear, but I ll elaborate for the benefit of any XP proponents who might be reading. Boyle s Law tells us that if pressure is reduced, air molecules move apart, occupying more space per molecule .

That s exactly what happens in an XP lab. Let s face it, people enjoy personal space. To deny that is to deny common sense. People can be forced into close contact for periods of time, but when the necessity (pressure) to be in close contact is reduced, they ll spread out. A we need to pair more scolding from the coach is the pressure. (Note: Real-life XP consists of daily scolding and self-flagellation in the form of We aren t doing enough of ___. )

A curious VP stopping by the lab is added pressure. The threat of finding yourself-without a job if you don t pair is tremendous pressure. It s interesting to see pairs form under pressure. It s even more interesting when people pretend to pair. One way developers achieve this is by sitting quite close together. From a distance, it s impossible to tell if they re working together or they re just two people sitting really close together. Either way, it looks ridiculous. Two people hunched over, attempting to make an interface specifically designed for an individual work is a visual oxymoron. Without a doubt, there s going to be an increase in neck and back problems in the developer community.

But what s even more amusing is what happens when the pressure is released. This may be in the form of a coach being in a meeting or perhaps on vacation. It could also be as a result of being very early or late in the day, or on a weekend . When the pressure is reduced, the developers, just like air molecules, adjust to a more natural distance. This natural distance consists of developers working at their own workstations. If fewer people are present than normal, developers will naturally choose a position one or two chairs down from the next person.

Peer Pressure and the Silence Factor

By far the most striking characteristic of developers in the XP lab is their inability to admit (or resistance to admitting) that they hate to pair. If they were to admit that they dislike pairing, they would go through a very unpleasant ostracizing process. The reason is that the worst thing that can happen to an XP developer is for someone to find out that he has a few disagreements with the process. I ve never experienced fear like I do now on any project I ve ever been on. This is key to understanding the XP world.

In a traditional environment, you would be able to say with impunity, I hate writing documentation. Contrast this to the XP world, where dissention is fatal. Even though XP proponents make a big deal about the ability to change the process, a few processes are nonnegotiable, pairing being one of them. Quite literally, the words of the prophets are written on the lab walls: Pair up! Or more precisely, all production code must be written in pairs. I now know methodology can become dogma to the extent of a religion.

 

Don t code, don t code, don t code so close to me . . .
Pleeease don t code so close to me . . .

^[6] Alistair Cockburn and Laurie Williams, The Costs and Benefits of Pair Programming, http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF, 2002.