Pair programming - yay or nay?

Anesthetize

So management in the company I work for have been very keen to push development teams to pair program, with the aim of increasing productivity and software quality. Having only had a small bit of experience with pair programming I'm still not sure what to make of it. However colleagues with more experience of it seem to have fixed feelings. Some see the benefits of it but others see it as a nuisance.

It certainly does have benefits as regards knowledge transfer and competence building. But does it really get tasks done quicker as opposed to developers working on them in parallel?

I'm interested in other people's thoughts and experiences with it.

stefanovich

Anesthetize wrote: »

So management in the company I work for have been very keen to push development teams to pair program, with the aim of increasing productivity and software quality. Having only had a small bit of experience with pair programming I'm still not sure what to make of it. However colleagues with more experience of it seem to have fixed feelings. Some see the benefits of it but others see it as a nuisance.

It certainly does have benefits as regards knowledge transfer and competence building. But does it really get tasks done quicker as opposed to developers working on them in parallel?

I'm interested in other people's thoughts and experiences with it.

Once you are competent it's of no use.

Anesthetize

stefanovich wrote: »

Once you are competent it's of no use.

I tend to look at it that way. If I know exactly what has to be done then I don't need much help from others. On the other hand if I am competent, and a more junior developer isn't, then it would be more useful to them than me.

Mostly I'd prefer if I didn't have somebody beside me spilling coffee on my lovely clean workspace

stefanovich

Anesthetize wrote: »

Mostly I'd prefer if I didn't have somebody beside me spilling coffee on my lovely clean workspace

Plus I lose the ability to type when someone is looking over my shoulder!

Idleater

stefanovich wrote: »

Once you are competent it's of no use.

Just like driving, if you think you know it all and have nothing else to learn you are wrong :-)

FWIW, I was involved in the beginning of agile XP programming and have used it in varying degrees to date.

One simple way of not having management think "OMG we're paying two people to sit at one computer" is to pair for a bit (learning/prototype/tracer bullet), agree some possible directions and split, followed by 20 goto 10.
Pairing can be 10 minutes over coffee to hours at one machine, nothing is fixed. The good takeaways for management is the increase in quality - because by pairing the tdd/bad should be better covered, the code review clearer, the knowledge spread wider and the overall maintenance/bug diagnosis quicker.

jester77

Meh, these days pull requests are a much more productive way to ensure quality. It made sense back in the late 90's when agile was taking off with the XP methodology, back then CVS was as good as it got and I can't remember there being any collaboration tools. These days we have tools like github, jira, etc to ensure quality control.

Raging_Ninja

What gave management this notion and what perceived problem are they trying to solve by introducing paired programming?

Giblet

We use pair programming to prevent knowledge silos, not for quality.

bpmurray

Pair programming works well for some and not so well for others. In particular, experienced developers often do things differently, so they can end up getting in each others way, ultimately reducing the quality and making everything slower. If there's an obsession to be more agile, I've found that TDD beats everything else hands down, for quality, cost-savings, speed to delivery, etc.

14ned

Anesthetize wrote: »

So management in the company I work for have been very keen to push development teams to pair program, with the aim of increasing productivity and software quality. Having only had a small bit of experience with pair programming I'm still not sure what to make of it. However colleagues with more experience of it seem to have fixed feelings. Some see the benefits of it but others see it as a nuisance.

It certainly does have benefits as regards knowledge transfer and competence building. But does it really get tasks done quicker as opposed to developers working on them in parallel?

I'm interested in other people's thoughts and experiences with it.

Marian Petre (http://mcs.open.ac.uk/mp8/) who is an academic who studies how software is made has unusually hard empirical results for this:

1. High performance software teams very rarely do pair programming.

2. High performance software teams very frequently do pair debugging.

According to her this holds true whatever the continent, language or culture, and unlike those who advocate some process or other based on belief or ideology, these correlations have hard figures sampled across many sites, times and organisations.

Now, moving onto personal opinion, I think pair programming can be very useful, if expensive in cost and time relative to alternatives, way to make a team of below average programmers perform above the sum of their parts. I've seen great outcomes from that. I've also seen it work well for fixed durations of time as a method of knowledge transfer, so for example where a senior programmer leaving a project is being replaced.

I've also seen it work badly where either the pair burn themselves out from lack of daily downtime, or arse around and get nothing done disrupting others around them. I've also seen it work badly when you pair the wrong kind of personality or type of programmer. Some programmers really do do their best work alone, even really alone a.k.a. working permanently from home or in an office far away (I would be one of these myself, I don't work well in any office with other people in or anywhere where I have to interact with others at times of their choosing).

I really don't think pair programming is a one size fits all technique. It's useful as one of many in the bag of software development processes. Deploying it across an entire division without regard to each team I think leads to bad outcomes, same as stamping ANY single process on all teams without local customisation leads to bad outcomes.

I do think pair debugging of particularly vexing bugs works extremely well and it's the one area I'd say me working alone has inferior outcomes.

I hate to say it, but excellent software teams tend to have no fixed ideology at all. They've figured out patterns which work well for them and make them excel, and it's usually some fluid hodgepodge of various well known processes which shouldn't work, but does for their particular team.

Niall

fergalr

14ned wrote: »

Marian Petre (http://mcs.open.ac.uk/mp8/) who is an academic who studies how software is made has unusually hard empirical results for this:

1. High performance software teams very rarely do pair programming.

2. High performance software teams very frequently do pair debugging.

According to her this holds true whatever the continent, language or culture, and unlike those who advocate some process or other based on belief or ideology, these correlations have hard figures sampled across many sites, times and organisations.

Have you got a specific citation for that? She seems to have a large back catalogue?

https://scholar.google.com/citations?user=J7zsMn8AAAAJ


Incidentally one of her first papers I looked into is really interesting:
"Expert programmers and programming languages"
http://www.cl.cam.ac.uk/teaching/1011/R201/ppig-book/ch2-1.pdf

14ned

fergalr wrote: »

Have you got a specific citation for that? She seems to have a large back catalogue?

It's from her ACCU 2016 Conference keynote address.

Niall

Anesthetize

bpmurray wrote: »

Pair programming works well for some and not so well for others. In particular, experienced developers often do things differently, so they can end up getting in each others way, ultimately reducing the quality and making everything slower. If there's an obsession to be more agile, I've found that TDD beats everything else hands down, for quality, cost-savings, speed to delivery, etc.

I agree that pair programming isn't something that is going to suit everyone. Even when I'm working on something with someone, I'd rather divide out the work and work closely in parallel. We can then come together at any point to help each other out on something, discuss solutions or review each others code.

TDD definitely beats everything hands down. You can get things done so much quicker and pain-free with the fast feedback loop that TDD brings.

14ned

Anesthetize wrote: »

TDD definitely beats everything hands down. You can get things done so much quicker and pain-free with the fast feedback loop that TDD brings.

I'll agree that TDD definitely beats everything hands down for 80% of software developed right now using the current generation of tooling.

However some software can't be written using TDD, for example software designs you've no idea whether it's possible or not. You might suggest can't you write a feasibility prototype, scrap it and then do a final version using TDD? Sometimes yes, but also sometimes no, often commercial pressures won't allow the prototype to not be the final product. Some software is so cutting edge for example that attempting TDD kills the compiler, I currently have a library whose test suite murders Visual Studio 2015 Update 2 for example, it's very annoying. Some software it really is better to write the thing first adjusting and tweaking it as you go, then write its conformance test suite to lock in that design permanently so no regressions can ever occur.

Also, tooling is improving. I currently expect that the C++ libraries I write in 2020 won't need unit tests anymore because you can get LLVM to auto generate a suite of test code locking in the exact behaviour of a body of code. It requires guiding of course to prune down what needs to be fixed and what can float, but we're talking about an abstraction layer above manual unit test writing.

I look forward to it. Writing unit tests is boring and a waste of my time. I do think writing integration and the other types of tests can never be automated though, it requires human understanding.

Niall

stefanovich

bpmurray wrote: »

In particular, experienced developers often do things differently, so they can end up getting in each others way, ultimately reducing the quality and making everything slower.

I've had certain co-workers who are highly skilled and experienced but I literally cannot understand most of what they say. It's like our brains operate in a completely different way.