Reply to: Pair programming - how wide spread is it?

[Murder1]

My experience is that any process or method implemented without full understanding can give negative results.

Amen

[acontractor]

I have worked in Both Pair programming environment and scrum environment with two different companies. The Pair programming is a good concept provided everyone involved understand and on board. Sometimes companies bring this so that if they have too many senior devs. and for e.g. they cant promote on over the other (in permie.) which I think is wrong reason. My belief is that if you have few people who posses domain or dev. expertises in something then they can be a lead in that pair in that project while in another project someone else can. This way balance of who is driving the team is maintained.

Scrum can have very negative effect on developers if the top management dont understand why they are implementing the scrum. I worked for a company where the company actively encouraging their senior staff to do training etc. and it did helped moving project forward. In another company the senior management thought that Scrum is a tool from which they can control the developers and make developers more accountable.

My experience is that any process or method implemented without full understanding can give negative results.

[Willapp]

Holy buzzword bingo, batman!

Yes, it is indeed devised to leverage synergies and maximise bandwidth facilitating a streamlined pipeline and win-win situation. When combined with Agile techniques, pair-programming can push the envelope and enable deep-dive blue sky thinking to move forward on the 50,000 ft view of the entire project, expediting the win-win situation of making progress against the low hanging fruit and right-shifting the entire organisation allowing an under-pinning of land and expand strategies and empowering management and development with proactive, joined-up thinking to cover all directions of the compass in best-practise, big picture, value-added core business performance indicators.

Brilliant!

[darrenb]

All of these things have a good chance of succeeding when introduced by developers.

All of these things will just demoralize people when introduced by management.

The underlying motivations cause very different flavours of such practises to emerge. Is the motivation to improve the product, or is it to interfere and monitor and micromanage things because you don't trust your people?

[billybiro]

The point of pair programming is that two people working together is supposed to produce more than two people working seperately. When MBA wielding manages believe this, then you'll have pair programming. The evidence is that, done properly, it is indeed synergistic.

Holy buzzword bingo, batman!

Yes, it is indeed devised to leverage synergies and maximise bandwidth facilitating a streamlined pipeline and win-win situation. When combined with Agile techniques, pair-programming can push the envelope and enable deep-dive blue sky thinking to move forward on the 50,000 ft view of the entire project, expediting the win-win situation of making progress against the low hanging fruit and right-shifting the entire organisation allowing an under-pinning of land and expand strategies and empowering management and development with proactive, joined-up thinking to cover all directions of the compass in best-practise, big picture, value-added core business performance indicators.

[MyUserName]

What you are talking about is training, not pair programming.

Training is a part of pair programming, for both programmers.

[russell]

You do not need an excellent programmer, you just need one who is professional enough to put the needs of the project ahead of their ego and has the ability to learn.

Pairing an excellent programmer up with someone not as experienced will teach the less experienced programmer far quicker than them programming alone, it will also spread knowledge etc.

The expert will not be able to code as fast as if they were alone but the overall team speed measure over the long term will increase. Especially as it greately reduces maintenance overhead.

What you are talking about is training, not pair programming.

[Wils]

I've never seen information transfer happen in these meetings. For one thing 30-60s is only enough to cover the main area someone is working on, not anything useful about the tech/code. For another, everybody just sits looking bored waiting/dreading their turn to speak and then turns off until they can go do some real work..

I couldn't agree more. If we are all honest, the real purpose of the stand-up is to make the developer more accountable. It has little to do with knowledge transfer and everything do with justifying your income. I have seen some people become expert at doing very little but presenting it as though its a lot. And some very productive people not have their effort recognised because they don't the possess the same presentation skills. Particularly those who don't speak English as a first language.

[NotAllThere]

...To pair a great programmer up with a run of the mill will just slow down the whole development process. It's a moronic idea dreamed up by people looking to sell something.

“That which can be asserted without evidence, can be dismissed without evidence.”

Indeed.

[MyUserName]

It's rare to find 2 excellent programmers in the same company let alone the same team (excluding silicon valley). To pair a great programmer up with a run of the mill will just slow down the whole development process. It's a moronic idea dreamed up by people looking to sell something.

You do not need an excellent programmer, you just need one who is professional enough to put the needs of the project ahead of their ego and has the ability to learn.

Pairing an excellent programmer up with someone not as experienced will teach the less experienced programmer far quicker than them programming alone, it will also spread knowledge etc.

The expert will not be able to code as fast as if they were alone but the overall team speed measure over the long term will increase. Especially as it greately reduces maintenance overhead.

[russell]

It's rare to find 2 excellent programmers in the same company let alone the same team (excluding silicon valley). To pair a great programmer up with a run of the mill will just slow down the whole development process. It's a moronic idea dreamed up by people looking to sell something.

[oliverson]

You have, however, given a very good reason as to why pair programming is good.

People who roll up their sleeves and hack away have someone sitting next to them to keep them in check. For generating a design you have someone sitting there to bounce ideas of who is thinking at a different rate and possibly different way to you, therefore the design gets the benefit of both as you will be discussing these issues as you format things.

Do not forget that, like Agile, Pair Programming assumes that both programmers have the project's best interests at heart (well, it assumes that the programmers are professional enough to at least act that way at work!!!).

Unless both coders are hackers!

[d000hg]

You don't have to work in pairs to avoid the situation where one person hordes knowledge. You could encourage developers to talk to each other; I've always found the daily standup meeting quite effective.

I've never seen information transfer happen in these meetings. For one thing 30-60s is only enough to cover the main area someone is working on, not anything useful about the tech/code. For another, everybody just sits looking bored waiting/dreading their turn to speak and then turns off until they can go do some real work.

I suppose some places it's not like that, maybe places where the devs choose to do this rather than have it foisted upon them by managers who read about it in a blog.

[MyUserName]

I think the problem with pairing is there's a natural tendancy for people to show off their knowledge or to dive into coding a solution without actually thinking through the problem. People think at different rates and have different approaches. Most roll their sleaves up and start hacking away. I prefer to digest the problem, come up with a solution and 'then' start coding. I think my approach ultimately leads to better code than the hack and slash approach. In short I think pair programming sucks.

You have, however, given a very good reason as to why pair programming is good.

People who roll up their sleeves and hack away have someone sitting next to them to keep them in check. For generating a design you have someone sitting there to bounce ideas of who is thinking at a different rate and possibly different way to you, therefore the design gets the benefit of both as you will be discussing these issues as you format things.

Do not forget that, like Agile, Pair Programming assumes that both programmers have the project's best interests at heart (well, it assumes that the programmers are professional enough to at least act that way at work!!!).

[oliverson]

It's when the interview process involves pair-programming you have to worry. Interviews at stressful at the best of times but when you have somebody there next to you who has the responsibility of hiring you and they've seen the test scenario before a million times but you come in cold, then there's far more resting on this pairing than your normal day it's a bit too much.

I think the problem with pairing is there's a natural tendancy for people to show off their knowledge or to dive into coding a solution without actually thinking through the problem. People think at different rates and have different approaches. Most roll their sleaves up and start hacking away. I prefer to digest the problem, come up with a solution and 'then' start coding. I think my approach ultimately leads to better code than the hack and slash approach. In short I think pair programming sucks.