Paired Programming... Does it work?

We're doing this now - we came up with a 'buddy' scheme where the buddy basically 'spots' the developer - makes him work, checks and reviews work, and acts as team reporter for progress meetings.

This ensures the buddy knows the project inside out and that the developer is doing his job properly.

Not really deployed it properly yet, but seems to be working.
 
This is employed at my university. We're randomly paired up to tackle assignments together. My lecturer gave us a large ammount of research in PDF format that I can upload somewhere if you're interested.

In my opinion, in an education environment, it doesn't work too well. Although that's mainly because I find some of the people on my course difficult to get along with (for various reasons). In a workplace where everyone's friendly and such I can imagine it being worth a try.
 
Yes, yes, yes and YES! Do it, and do it hard!

We do it everyday, for just about every task. We cannot live without it. :) We actually prohibit anyone from working on software on their own. If we have odd numbers, we trio. :)

We also employ the pomodoro technique which goes EXCELLENTLY with pair programming.
 
Last edited:
dave-lew99 said:
We're doing this now - we came up with a 'buddy' scheme where the buddy basically 'spots' the developer - makes him work, checks and reviews work, and acts as team reporter for progress meetings.

This ensures the buddy knows the project inside out and that the developer is doing his job properly.

Not really deployed it properly yet, but seems to be working.
Click to expand...
This is actually a bad way to employ it. You shouldn't have a senior/junior pattern to it. It should just be two people working together at the same terminal, tackling the same problems. Sure, you'll have one person more experienced than the other, but it's not a competition. :)
 
Pair design is useful. I think pair programming is a little too much of a loss on resources to be honest. Also a lot is dependent on the individuals and culture in how well they work as a pair. By culture I'm comparing Indian, Czech, US, UK and Irish development teams.
 
Some studies have proven it to be more efficient, whilst others no different, and none negative impact: http://en.wikipedia.org/wiki/Pair_Programming#Scientific_studies

but in personal experience it's a more enjoyable way to work and you get much fewer bugs. It is also absolutely invaluable for sharing knowledge of the software - i.e. at least two people will know about the product, not just the one person writing it.
 
Last edited:
Yep, has completely transformed sterile banking environments and a couple of large corps....

They're actually now fun places to work.

Depends on work methodology and how well it's being implemented.

Thing is that some devs love it but others just can't do it.
 
Dj_Jestar said:
This is actually a bad way to employ it.
Click to expand...

Seems to be working so far ;) It's not really junior/senior - for example i could easily be my boss' 'buddy' and be telling him if i think his work isn't good enough and so on (i have and i do, we've got that kind of dynamic in our office). So the 'lead' person doesn't have anything to do with their job position in the company.
 
If it's working for you, great, but that's what is bad about it.. there shouldn't be any kind of "your work isn't good enough" as you are meant to be working together, not one person working and the other grading it. :) Pair programming isn't a review process. It eliminates the need to review, yes, but only because you have two people working on it at the same time. Not one person working, and the other reviewing. :)
 
Yeah think of it this way ...

" 2 minds are better than 1 "

It also has a severe impact on the way you code. Typically I find writing more manageable, maintainable code - no more hieroglyphs. Not only that, the knowledge pool is increased to the power of 2 as you work your way through various projects.

But again I have to put emphasis on whether the company has embraced the flavour of methodology (agile,xp,scum et al) fully. This is my top question at all large corp job interview.
 
That I agree with too: Pair programming, whilst achievable, isn't ideal for a waterfall, legacy development cycle. It's really suited for Agile and Lean. :)
 
If the disparity between the two people's experience is too large then you might eventually have one unhappy experienced programmer. Depends whether he likes teaching or not. Some people do, some don't. Some people would like to teach if they didn't already have a huge backlog of more important things to be doing. But likewise, an unexperienced programmer may find it frustrating watching the amount of time the experienced guy spends on fine details like getting namespaces and type names correct and what not.

Also depends whether the company can afford it. From a resources point of view, pair programming could be considered wasteful in a small company. They'd much rather have the experienced programmer knocking out good code and releases. Whilst the unexperienced programmer is busy bashing his keyboard in chaotic ways trying to create something that resembles what his boss asked for.


Of course, that's not to say pair programming doesn't work when it's two experienced programmers. I just don't have any experience myself on that so can't really comment. I can imagine that it would be utterly awesome though.
 
NathanE said:
Some people would like to teach if they didn't already have a huge backlog of more important things to be doing.
Click to expand...
That's mentoring, not pair programming. The person who isn't driving needs to be reviewing what's going on, making suggestions and catching problems. You should swap around regularly. With a very junior person, this isn't going to be possible.

NathanE said:
From a resources point of view, pair programming could be considered wasteful in a small company.
Click to expand...
I've heard this a lot, and it grates. (A bit like those who say agile is for hackers who can't be bothered to specify anything up-front.) The benefits of pair programming are numerous, but if it isn't a good fit for your team, don't do it.
 
Thanks for the comments,

It seems that the majority of people seem to like it.

I guess that the drop in efficiency isnt too great as developers are constantly accountable to each other (so less gazing out the window or surfing the net!). The bug count should drop nicely too.

I will look into the Pomodoro Technique too... thanks DJ Jestar.

I will be implementing it in an agile environment (we use scrum methodology) ~ so im looking forward to the feedback in our daily stand-up meetings.

On a side-note.

Pairing experienced & inexperienced developers together sounds a fantastic way to help develop multi-disciplinary teams. An essential best practice for scrum :-). Many view individual heroics as an anti-pattern / pitfall within agile teams.
 
NathanE said:
If the disparity between the two people's experience is too large then you might eventually have one unhappy experienced programmer. Depends whether he likes teaching or not. Some people do, some don't. Some people would like to teach if they didn't already have a huge backlog of more important things to be doing. But likewise, an unexperienced programmer may find it frustrating watching the amount of time the experienced guy spends on fine details like getting namespaces and type names correct and what not.

Also depends whether the company can afford it. From a resources point of view, pair programming could be considered wasteful in a small company. They'd much rather have the experienced programmer knocking out good code and releases. Whilst the unexperienced programmer is busy bashing his keyboard in chaotic ways trying to create something that resembles what his boss asked for.


Of course, that's not to say pair programming doesn't work when it's two experienced programmers. I just don't have any experience myself on that so can't really comment. I can imagine that it would be utterly awesome though.
Click to expand...
"more important things to be doing" .. honestly, getting those inexperienced developers up to speed is the most important thing you can have in any, big or small, workplace. :) Save for "emergencies."

There is also the "Beginner's Mind" effect, where an unlearned mind can produce new improvisations where as a experienced mind will try to repeat previous patterns to achieve goals. :)
 
Last edited:
Dj_Jestar said:
"more important things to be doing" .. honestly, getting those inexperienced developers up to speed is the most important thing you can have in any, big or small, workplace. :) Save for "emergencies."
Click to expand...
I would agree with this, although leaning slightly on the side of "ideal world only". But only if I could "see" immediately that the person was going to get there eventually and within a reasonable amount of time (i.e. a few months at most).

To me, getting someone up to speed should be merely giving them pointers. Like "this is what this assembly does, this class is pretty important and does this, oh this algorithm is pretty neat and here's how it works, here are the docs".

It should not mean teaching basic things about the programming language.

The only way they're going to learn is by getting their hands dirty. Every time they make a unit test fail it means they're learning something new about the codebase.

As said above though, clearly this is mentoring - not pair programming.
 
The line does blur somewhat, but tbh.. there really is no need to be so clinical about everything. If you have a member of your team that is not up to speed, be it because they are not experienced with the product, or the team member hasn't used the platform/language much is pretty much irrelevant. Your *team* is going to suffer because of that inexperience. Now, if you want to shift all the blame/responsibility onto that one member, throw some books at them and instruct them to get learning (or even just sack/replace them) then that's your prerogative, but it'd be far better to just help them, no? Morale would be better - no feeling of "I need to know this or I'll be disciplined" - and it's just altogether more friendly and fluffy.
 
You must log in or register to reply here.
Back
Top Bottom