Pair programming - how wide spread is it?

[VectraMan]

I think you are completely missing the point. It isn't about having someone "watching over your shoulder and directing you" or you doing this to someone else: it's about sharing the development responsibility - design, coding and testing. If you work with someone who knows their stuff and is a good communicator - and you are the same - it can be a very effective technique.

Don't knock it until you've tried it.

I figure it works one of two ways. Either one person dominates, and the other just sits there twiddling their thumbs taking the client's money whilst thinking about their garden, OR there's so many arguments and discussions about every tiny detail that it takes 10 times longer to get anything done than one person on their own could manage. And who becomes a developer if they're a good communicator?

Small close knit teams also share development responsibility; regularly work together on important design decisions etc., and also help each other out and look over each others shoulders from time to time as and when required. But sharing a keyboard?

Of course I wasted 2 hours today in a sprint debrief meeting. Unfortunatley it seems impossible to avoid the software engineering BS these days, and it's just a matter of degree.

[SueEllen]

Of course I wasted 2 hours today in a sprint debrief meeting. Unfortunatley it seems impossible to avoid the software engineering BS these days, and it's just a matter of degree.

With every methodology there are people it doesn't work for due to the fact they like wasting time, and people it works wonderfully for.

[nomadd]

It's currently being used in one of the projects in our programme.

It can be a cringe worthy...having manly bonding sessions...

Hmm... I'm not quite sure your team has got the hang of it. Still, as long as what you are doing is keeping you happy...

[kingcook]

I figure it works one of two ways. Either one person dominates, and the other just sits there twiddling their thumbs taking the client's money whilst thinking about their garden, OR there's so many arguments and discussions about every tiny detail that it takes 10 times longer to get anything done than one person on their own could manage. And who becomes a developer if they're a good communicator?

Funny, but that's how i would imagine it to be too.

Real developers can manage by themselves

[Wils]

Thanks folks. Glad I am not alone in finding it a horror. I fully understand that it has benefits in code quality and knowledge sharing, but it's some price to pay for it. I have seen people putting a clock in front in them and spend 25 minutes working then 5 minutes break - all day, every day. When I quizzed them about it they said it is stressful and exhausting. Why would anyone voluntarily submit to that?

[darrenb]

If you work with someone who knows their stuff and is a good communicator - and you are the same - it can be a very effective technique.

Yes, but once it is introduced in a team, then everybody has to do it. The problem is that in every team at least one or two people will be difficult (e.g. "climb the ladder" types that try to make everyone else look bad), and doing pair programming with them will be a nightmare. This makes pair programming a game of Russian Roulette. That's in a good team. In an average or bad team, there will be more political types.

So, basically I am saying that the idea of pair programming is far too ambitious for engineering teams given the political structures and hiring practices that exist today. It is generally unquestioned that the more communication in a team the better, but the reality is that not all communication is good communication. Let's say you have an average team with 50% productive types and 50% political types. Then the theory is that pair programming would educate the 50% unproductive ones and make them productive, bringing you to 100% productivity. But it's much more likely to demotivate and even drive away the productive types, so you're actually going to 20% productivity.

[billybiro]

Interested to know how many contractors are in development teams that are pair-programming (particularly serverside devs - Java/C#/C++). I sometimes see it crop up in job ads and know some teams where I am now do all there work in pairs, often using the pomodoro technique.

Is this something contractors *need* to embrace to stay employable?

Pair programming is as rare as rocking horse $4it. There's a very simple reason for this. The MBA-wielding managers who have to decide upon things like staffing levels etc. will never entertain this idea for the simple reason that, if they're employing (<cough>contracting</cough>) two people, they'll want 2x the output. No manager in his right mind will have two people working together to produce the same that one person can produce.

In short, don't worry about pair programming. In the real world, it's largely non-existent.

[jezosaurus]

Never done it formally, but I liked the idea, so I had a go.

I often pull the "lets work through it together" - not just on programming - it can be anything.

I know I'm pair working, they don't, which means I can team up with someone when I need to and get them to do what I need doing much faster than if I tried to do it myself or the typical back and forth of getting them to do something I'm dependant on.

It's incredibly effective. It can be frustrating and takes a lot of patience and people skills, but it definately works.

I don't tell people we're pair working - that way nobody ever gets to slag the technique off. Most people are either so set in their ways they think it's nuts, or not patient enough to keep it up for long.

[MyUserName]

It is just one of those things that will work if both people are skilled and professional.

If you have lazy slackers, politicians etc then they will probably break any method you put into place other than one which takes so much time and effort it sucks the productivity out of the more efficient people.

With two skilled professionals who are working properly you can get a lot of good mileage from this method. The code and design get automatically reviewed, it helps break down large problems and spreads system and technical knowledge around.

It does not work well if you have the kind of engineer who likes to horde knowledge. To be honest, combating this tendancy is one of the objectives of pair programming as it is bad for the team.

[BrilloPad]

I figure it works one of two ways. Either one person dominates, and the other just sits there twiddling their thumbs taking the client's money whilst thinking about their garden, OR there's so many arguments and discussions about every tiny detail that it takes 10 times longer to get anything done than one person on their own could manage. And who becomes a developer if they're a good communicator?

Bigger issue is who gets the blame when it goes wrong?