Welcome to AgileShout

Question

1

I've got a client that I would like to try pair programming with, but they've been a little reluctant, and with good reason. His fears:

I'm paying two people to do the same work - is the task they are working on going to be done twice as fast or twice the quality, or a mixture?
Which person is responsible for an item and how do I keep track of it?

I guess all valid and normal points. My rebuttal is with pair programming - yes it might cause a task to be done a little slower, however the quality will be much higher and less likely need to be revisited due to bugs, but that doesn't seem to justify the cost to him. He's agreed to try it for a week - but I don't think that is long enough to see the benefits.

So, my questions are..

Does anyone have a resource, online or otherwise, that has done case studies with pair programming? Metrics such as a percent change in amount of time spent fixing bugs would be cool.
Does anyone else have any tips to convincing a client that pair programming is a practical approach to software development?
What is, in your opinion, the minimum length pair programming should be done before you can measure it's effectiveness?

flag	asked Nov 4 at 14:44 John Merriwether 305●7

Ilja Preuß · Accepted Answer · 2009-11-11 12:53:08Z UTC

We've convinced our sceptical management after a week of pairing. We had already lots of experience pairing with each other on other projects, though.

"Paying two people to do the same work" - the two are only doing the same work in the same sense the driver and the navigator of a rallye team do the same work. A driver who also has to look at the map to find his way is going to be much slower.

"Which person is responsible" - why does he care? The solution will depend on the answer to this question.

I've gathered a couple of resources over time - including one or two case studies - that you might want to take a look at.

thoughtadrian · Answer 2 · 2009-11-21 13:13:29Z UTC

Laurie Williams, from NC State University has written extensively on pairing.

Here are some references I've collected over time:

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 33, NO. 2, FEBRUARY 2007 Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise Erik Arisholm, Hans Gallis, Tore Dyba° and Dag I.K. Sjøberg

J T Nosek, "The Case for Collaborative Programming," Communications of the ACM, March 1998

The Costs and Benefits of Pair Programming, by Alistair Cockburn and Laurie Williams

Williams, L., et al., Strengthening the Case for Pair-Programming, in IEEE Software. submitted to IEEE Software. Online at www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF

Williams, L.A. and R.R. Kessler. The Collaborative Software Process. in International Conference on Software Engineering 2000. submitted for consideration. Limerick, Ireland. Online at www.cs.utah.edu/~lwilliam/Papers/ICSE.pdf

Some good research is available here: http://simula.no/research/engineering/publications

Convincing the client to try Pair Programming

2 Answers