Productivity: numProgrammers2numProgrammers? Right?

Productivity: numProgrammers/2 == numProgrammers? Right?

In a white paper on pair programming, Alistair Cockburn and Laurie Williams write:

The affordability of pair programming is a key issue. If it is much more expensive, managers simply will not permit it. Skeptics assume that incorporating pair programming will double code development expenses and critical manpower needs. ^[11]

This is a common argument against pair programming: Surely with two people-sitting at one computer, concentrating on one program, only half as much work would get done. The usual response is that pair programming actually increases productivity in the long run because the code is of a higher quality; in other words, eventually just as much code gets written (or, to be more precise, eventually the same amount of functionality gets implemented ”if it s of higher quality, then it will probably involve fewer lines of code). We ve found that doing some detailed up-front design before coding allows even solitary programmers to produce very high-quality work!

This is one area that we see a circular argument in XP emerge. In Extreme Programming Explained , continuous integration is justified in part by the fact that because the team is programming in pairs, there are half as many streams of changes to integrate ^[12] ”in other words, half as much code is being produced.

Coder s Little Helper

(Sing to the tune of Mother s Little Helper by the Rolling Stones)

What a drag it is smelling code

Things are different today
Since my pair has gone away
And the new one comes to work when he is fried

And those onions that he ate
Make me want to leave the state

I go running for the shelter
Of the coder s little helper
And it helps me through the day
Until I can get away

Breath mints pleeeeease
Take four of these
Go to the store
And buy some more

What a drag it is smelling code . . .

VoXP
Voice of eXPerience: Overuse of Pair Programming

by David Van Der Klauw

I believe that overuse of pair programming is a major flaw in XP. Before I comment on pair programming ( pairing ), I want to make the point that it is a complex issue, not a Boolean variable to be decided Yes or No, Right or Wrong.

Pairing is a lot like marriage in the types of questions and answers that arise. Imagine the reaction I would get if I made a few general comments about the benefits of marriage and then insisted that every person should be married and that CompanyXYZ should employ only married people. There would be outrage. Yet this is exactly how the complex issue of pairing is approached by many people.

Learning by Pairing

Remember a lesson at school or university. The teacher gives a general introduction of the topic, works one or two examples on the board, and then gives you some problems to attempt by yourself. You consult the board and/or your textbook , and then attempt the questions. Should you have trouble, the teacher is there to help.

Imagine how silly it would be if instead of all this, the teacher just sat beside you and you both commenced working on the problems together. Whenever your writing slowed, the teacher told you what to write, and when you were confused , the teacher took your book and completed the problem instead of letting you think it through and work it out yourself.

This is exactly what we do with our pairing. To me, the worst aspect of pairing is that it prevents me from stopping, investigating, and learning at my own pace when the need arises. When I am pairing, I have the responsibility not to waste the time of or bore my partner as I investigate something. As a result, I will often skip the opportunity of learning or investigating. Pairing raises the cost of learning and wastes many opportunities for investigation and improvement of my skills and the product.

Let Them Eat Cake

Is pairing better than working alone?

It is better in the same way that cake is better than bread, wine is better than water, and meat is better than vegetables. It is better in the right circumstances, but it is definitely not better for all circumstances.

How Much Meat Do We Need?

I tried to find an analogy to show how much pairing we should do. The best I could find is meat versus vegetables.

Vegetarians eat vegetables and do not eat meat. Without debating that topic, let s agree that while it s possible to get everything your body needs from vegetables, it s difficult. Most vegetarians will freely admit this. Therefore, a lazy vegetarian who neglects to monitor her diet would be better off eating some meat.

I ve made a graph showing the health of such a lazy vegetarian as she replaces vegetables with meat.

The High gain area is where the meat is providing the vital trace elements, iron and protein that the body was previously deprived of.

The Cost exceeds diminishing return area is where the high percentage of meat increases the amount of fat and free radicals, while not providing any further health benefit.

The Disastrous exclusion area is where the 100% meat diet causes severe problems due to the total absence of certain vitamins and fiber that come only from vegetables.

The Pairing Graph

Now I have made a graph showing the productivity of programmers who replace solitary programming with pairing (the figures shown here are purely illustrative ).

The High gain area is where the programmers pick up those vital tips and knowledge that can only be learned from watching another programmer in action. As solitary programmers, they were deprived of these.

The Cost exceeds diminishing return area is where the high percentage of pairing increases the time taken, frustration, and so forth, while not providing any further benefit to the tasks .

The Disastrous exclusion area is where the 100% pairing causes severe problems due to the total absence of certain learning and experience that comes from only solitary programming and study.

How Much Pairing?

I recommend that the pairing level be adjusted to its optimum. How so? Well, I don t have a crystal ball to tell me the perfect levels, so I suggest a method that can be used.

Regularly ask the programmers if they want more or less pairing. Adjust the level a little bit at a time by majority vote, until half want more and half want less. Once this point is reached, consider whether the pairing level can be further adjusted on an individual person and/or task basis.

Two Minds Are Better Than One

Two minds are better than one. But then again, a chain is only as strong as its weakest link, a train is only as fast as its slowest carriage , and too many cooks spoil the broth. Which adage applies to pairing?

No one will argue that in many situations two minds are better than one. Therefore, all CompanyXYZ programming should be done in pairs if we make a few further assumptions:

• Putting two people in front of one computer automatically makes their minds work together effectively.

• CompanyXYZ is happy to pay twice as much to get the better result.

• Programmers enjoy pairing and won t leave CompanyXYZ for an alternative arrangement.

Is the Cost Justified?

When the value of pairing is questioned, its supporters will often point out one case in which a partner was helpful. They use this as proof that all coding should be done in pairs.

This is a classic case of the one- size -fits-all flaw. I ve paired now for more than 6 months. I ve had times when my partner taught me stuff, helped increase my speed, and found bugs I missed, and I ve had a few good chats and great fun on some days. That s not good enough.

It s necessary to do a proper cost-benefit analysis of the practice of pairing. For something to be justified, it isn t good enough to find one benefit. Benefits must exceed costs and there must be no better alternative.

Don t ask

• Can a partner ever be of any value?

Do ask

• Is a partner of sufficient value to justify the cost?

• Does the partner cause additional problems?

To pay off, pair programming must deliver the average task in half the time it would take a solitary programmer to deliver the task to the same quality. My experience indicates that this order of speed increase isn t occurring. In fact, I think many tasks take much longer.

XP proponents will come back with two arguments:

• Sometimes the quality of work of a pair of programmers is higher than is achievable by a single programmer.

• Occasionally, a pair of programmers will rapidly solve a problem that a solitary programmer would be stuck on.

Rather than dispute these claims, I ll concentrate on the impact of the far more frequent occurrence where the pair doesn t get the task done faster and, in effect, takes twice the hours required for the job.

When you invest money, a sobering fact is that to break even after a loss, the percentage gain you need is greater than the percentage loss taken. For example, a 10% loss needs an 11% gain to take you back to even, a 20% loss needs a 25% gain, and a 50% loss needs a 100% gain. It turns out that these mathematics apply to XP s pairing with equally alarming results.

Consider the case where a pair is normally taking 1 hour to do tasks that take a single programmer 2 hours. In this case, a pair is as effective as a single programmer.

Now consider a situation in which the pair fails to work faster on just one task and instead takes the full 2 hours. In this case, to catch up the pair would have to work at twice their normal rate for the next two tasks. That s right, after taking as long as a single programmer on just one task, the pair would need to work at four times the speed of the single programmer for the next two tasks just to catch up.

You do the math if you don t believe me. I believe that in the real world, a pair will often take as long as a single programmer to do a task. They may occasionally work faster, the quality of their work may even be higher, and they may avoid getting stuck occasionally. But on balance, the frequent slowness will overwhelm these benefits, as the mathematics shows.

Three s a Crowd

If two minds are better than one, are three minds better than two? If it makes sense to place two people on one computer, then why not turn up the volume, take it to an extreme, and place three or four people on one computer?

Don t laugh this off ”it s a very important question. The defense of pairing relies on certain hard-to- prove claims about better quality, knowledge sharing, and collaboration. All of these claims support tripling and quadrupling in addition to pairing.

When I asked [our XP coach] , he told me that any more than two people results in slower communication and decision making because there s more than one channel of communication. I find this answer to be unconvincing. Surely, the fastest communication and decision making occurs within the brain of a solitary programmer.

When it comes to programming, I think two is a crowd.

Laborer or Artist?

In my analysis of pairing, I thought about all kinds of work where people worked as a pair. Police officers and airline pilots pair for safety and backup. Laborers pair for greater lifting power.

People in creative professions don t pair. Remember, too many cooks spoil the broth. Can you imagine two painters creating a masterpiece by taking turns with the brush?

Most professions don t pair simply because the cost isn t justified. Bus drivers, taxi drivers, bank tellers, judges, teachers , and most workers in other professions do the job with the smallest unit that can do the job: one person.

Is a programming job more like the jobs that justify pairing or is it more like the jobs that don t justify pairing? I think programming is more like the jobs that don t justify pairing or aren t suited to pairing.

Who Likes Pairing?

Forced 100% pairing is like a forced marriage. It might work out, but it would surely be better if it was voluntary and stood on its own merits.

Ideally, the forced pair would be ideal at pairing and would work ideally together. In the real world, however, things are a bit different. In the next few paragraphs, I make a few generalizations that I ve placed in italics. These aren t absolute truths, but they re generally true.

When pairing a bossy and quiet person, the bossy person will tend to dominate-the quiet person. It s likely the quiet person will dislike pairing, whereas the bossy person will probably like the extra power he has. Bossy people like pairing, quiet people do not.

When pairing an expert with a novice, the novice will tend to slow down the expert and the expert will tend to teach the novice. The novice will probably enjoy this arrangement, while the expert will probably not. Novices like pairing, experts do not.

When pairing a high achiever with a low achiever, the high achiever will get less done and will no longer be able to take credit for the high achievement. The low achiever, however, will get more done and will be able to take partial credit for the work, as well as avoid the criticism and responsibility for her previous poor results. Low achievers like pairing, high achievers do not.

Although my statements are only generalizations, if they re correct they tend to suggest that if 100% forced pairing was brought into a company, quiet, highachieving experts would dislike pairing and leave the company, while bossy, low-achieving novices would like pairing and stay.

I didn t write this section to insult any particular person or to infer characteristics to someone who likes pairing. I wrote it simply to provoke thought.

Stick to the Task

XP claims that when programming alone, programmers tend to take experimental detours rather than sticking strictly to the task. XP claims this is a serious problem and solves it by pair programming, with strict estimation and tracking of time taken.

I have something very important to say about this. I believe that the experimental detours are good. They are vital learning that most programmers need. Think about it: Why do so many programmers do it? It s because it comes naturally. Do programmers naturally do a stupid thing, or do they naturally do a sensible thing?

When is the best time to investigate something that you don t understand fully? When you come across a task that might benefit from it, when the task is right there fresh in your mind.

Under XP, you should make a note of the possible spike, complete your task, and then discuss the possible spike with your team, write it up on the board as a spike, and do it. If something good comes from it, you discuss it with the team and customer, and then write a test for it and include it in the production code (working as a pair, of course). Is it any wonder that these investigations never get done under XP?

What happens if you just have a nagging thought that a really useful function or object lies just around the corner? How do you explain that to the team and get permission to do it?

Now that I ve suggested that experimental detours are good, I know what the XP proponents will argue. They will ask how you stop a programmer from spending all of her time on useless detours. Self-discipline and common sense are the answers.

If you ve just spent half a day on an unfruitful detour , then it makes sense to stick strictly to your tasks for the next day or two so that you have something to show for your effort.

An unproductive programmer, whether prone to detours or otherwise , will be obvious from the lack of output in the long run. Similarly, the high productivity of a creative, detour-taking programmer will also be obvious in the long run, even if the odd day is wasted on a detour.

 

^[11] Alistair Cockburn and Laurie Williams, op. cit., p. 3.

^[12] Kent Beck, Extreme Programming Explained: Embrace Change (New York, NY: Addison-Wesley, 2000), p. 68.