Archived

This topic is now archived and is closed to further replies.

Does anyone actually use pair programming?

This topic is 5309 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

This post is a bit of a troll but here goes. I do not see the benefits of pair programming. You have one person programming and the other just watches. Sorry, the other person interjects every now and then to make some comment and try to change the programmer''s mind. Now it may seem all hunky-dory in the ivory towers that XP was concocted in, but watching someone else program has to be the single most boring thing ever. I fall asleep frequently when I''m not programming. It is a waste of a person. I''m an intern and it pisses me off to no end to pair with someone. Why? Because I''m expected to yield the computer to the ''real'' programmer and then I just watch as they have crap like 5 classes in one source file, methods that need refactoring badly, inconsistant naming conventions, and to be asked for advice that they don''t take anyway. Its about as useless as some UML diagrams, thats for sure.

Share on other sites
quote:
Original post by antareus
This post is a bit of a troll but here goes.

a bit ?

Share on other sites
I agree. If I had to watch someone programming instead of doing it myself, my head would explode. I can''t stand having to help a co-worker with code and watch them stumble through it with no clue about what''s going on. If a person can''t sit down and write code without someone guiding them step-by-step or just by copying code from other sources, they shouldn''t be a programmer. Anyway, back to the topic--I''ve discussed the whole team programming thing (isn''t it actually called "Extreme Programming"?) with some previous employers, and none of them seemed to take it too seriously. Interesting concept, but just not practical at all.

Share on other sites
I''ve done some pair programming with a classmate and at work. In both cases, it worked out very well. Having said that, some of the things I''ve noticed are:
- both programmers need to be approximately the same skill level otherwise someone gets bored
- pair programming for routine coding (setting up GUIs, etc) is a waste of one person''s time (at least)
- debugging as a pair seems to work REALLY well
- the quality of the programming is heavily affected by both people''s moods during any given session
- coding style needs to be similar

The biggest downside I see to pair programming is that it doesn''t double productivity so you end up taking more time than using an "interactive" programming session where the coders work side-by-side on their own work, but exchange ideas and feedback frequently. Again, this technique is entirely dependent on coder-personality and, in general, doesn''t work if any of the coders involved have more than a minimal ego.

All in all, I don''t believe many people are going to have good experiences with pair programming because most times, the pairing isn''t a good match. I keep hearing stories about junior programmers pairing with senior programmers. That''s not pair programming, that''s mentoring and to try and pass it off as pair programming just gives the whole thing a bad name. Of course, I''ve also found that most "senior" programmers (at least in mid-to-large corporations) have become complacant with their positions and have lost their edge...

That you may see the subtle wonder
Of the worlds we live in...

Share on other sites
It''s better to have one person program alone, then have code reviews every so often so others can critique the work. The goal is to get multiple eyes on the code to catch things and provide differing viewpoints. XP, IMHO, doesn''t do that very well unless:

1) The programmers are equal in intelligence and programming ability and (more importantly, I think)
2) the programmers are of the same seniority in the organization.

Having an intern sit around watching someone else program is not XP. It''s Fubar.

Share on other sites
quote:
Interesting concept, but just not practical at all.

Yes, but its the latest fad that we all have to be in on! We''re going extreme man!

quote:
pair programming for routine coding (setting up GUIs, etc) is a waste of one person''s time (at least)

Thats the problem: it is not really tricky work at all, and there is no design involved.

quote:
doesn''t work if any of the coders involved have more than a minimal ego

Exactly, I have a big ego.

quote:
Having an intern sit around watching someone else program is not XP. It''s Fubar.

Or bullshit, call it what you want.

Sorry, my internship seems to have turned sour on me.

Share on other sites
I''m not a professional so I don''t have much experience programming with others, but I think it works best if each person works on their own file. The file can be reviewed by others with updates/fixes made by them, but primarily a common interface is drafted together and then each person writes their own file geared towards implementing some part of it.

~CGameProgrammer( );

Share on other sites
You can''t pair-program an intern with a developer - you''d have to pair program two interns or two developers. I wouldn''t listen to anything an intern had to say either .

Compare the time wasted during code reviews to the time wasted during pair programming. The idea is you don''t need a formal code review, nothing gets done during them, and everyone sits there and nit-picks. Then afterwards, someone has to take their notes and go fix stuff – rather inefficient. With pair-programming you’re suppose to can the formal code reviews, and the back-seat-programmer does the review online, in real-time. It takes two developers not the whole team, and problems are fixed when they are discovered.

We follow the laissez-faire policy where I work, where each developer can do just about whatever they want on their projects. Occasionally a couple of us write code together, which usually consist of me bitching about how crude someone else''s code is. We have impromptu design meetings frequently and team debug sessions once-in-a-while.

My boss considers pair-programming as a policy to be a tremendous waste of resources, though he''s not at all opposed to us working together on particular problems.

Share on other sites
quote:
Why? Because I''m expected to yield the computer to the ''real'' programmer and then I just watch as they have crap like 5 classes in one source file, methods that need refactoring badly, inconsistant naming conventions, and to be asked for advice that they don''t take anyway.

That doesn''t sound like pair programming. I think you''re getting it confused with something else. You''re supposed to talk not seethe.

Share on other sites
I can not work like this, every time someone looks at my back or my hands when i''m doing something, i always, i say alway mess up

Share on other sites
quote:
Original post by Estor
I can not work like this, every time someone looks at my back or my hands when i''m doing something, i always, i say alway mess up

We''re watching you, Estor

Share on other sites
I have done pair-programming at university, as everybody i guess, and it really sucked. I was in the opposite position (doing the code while somebody was observing), and i really felt i was the only one working. The only one to deserve a good mark, basically..

Professionnally i haven''t done pair-programming (and would object at doing so), but i have done tons of "pair-debugging", and that''s really wonderful. Because when debugging you generally have to type very little, it works very well, and the bugs were effectively found twice as fast.

Y.

Share on other sites
quote:
Original post by Anonymous Poster
quote:
Original post by Estor
I can not work like this, every time someone looks at my back or my hands when i''m doing something, i always, i say alway mess up

We''re watching you, Estor

Down in front AP, I can''t see...

Share on other sites
The initial development takes only around 20% of the total development time. The theory is that if you have 2 pair of eyes during the coding then you can radically reduce the bugs so you end up with a net efficiency gain. I have seen it work and when it does it works very well. I have also seen it fail. Egos/arrogance, incompatible skill levels, differing styles etc will break it.

Share on other sites
i''ve done it with a friend of mine, and the productivity of him (i was watching and giving tons of tips) gained much.

i was merely saing on what we try to solve together, and he coded it, and i debugged at codingtime.

it worked very very very very well. but it definitely depends largely on the persons. and the mood. and the daytime. and what to code. etc.

"take a look around" - limp bizkit

Share on other sites
quote:
Original post by Anonymous Poster
quote:
Original post by Anonymous Poster
quote:
Original post by Estor
I can not work like this, every time someone looks at my back or my hands when i'm doing something, i always, i say alway mess up

We're watching you, Estor

Down in front AP, I can't see...

Today You can watch, im not doing anything
I'm only on www.gamedev.net.

[edited by - Estor on June 3, 2003 7:27:32 AM]

[edited by - Estor on June 3, 2003 7:27:51 AM]

Share on other sites
quote:
Original post by antareus
I do not see the benefits of pair programming.

So?
quote:

You have one person programming and the other just watches.

That''s not pair programming.
quote:

Now it may seem all hunky-dory in the ivory towers that XP was concocted in

XP is not an academic invention.
quote:

I fall asleep frequently when I''m not programming.

What does that have to do with pair programming? Perhaps you have narcolepsy.
quote:

It is a waste of a person.

That''s your opinion. It certainly doesn''t appear to be based on any rational thought or decent practical experience, particularly as...
quote:

I''m an intern

So don''t go out into the real-world with your opinionated attitude that pair programming cannot be of any benefit.
quote:

Because I''m expected to yield the computer to the ''real'' programmer and then I just watch as they have crap like 5 classes in one source file, methods that need refactoring badly, inconsistant naming conventions, and to be asked for advice that they don''t take anyway.

That''s not pair programming either.

Share on other sites
I get the impression that people understand pair programming as being:

''put two people together to program''

This much can be worked out by anyone with a vague grasp of the english language. However, there is actually a whole methodology behind Pair Programming.

ObjectMentor.Articles

PairProgramming
TestDrivenDevelopment.BabySteps

Share on other sites
I told this in a previous pair programming topic but I might as well say the same thing again since I see so many negative comments about PP here. I did PP with my friend and it worked perfectly. Communication was good, both were open to new ideas and we were roughly on equal skill level. We didn''t really encounter many bugs at run-time since most of them were noticed by either one while coding (usually by the one who wasn''t coding, since he had a different ''feel'' to the code). We also changed seats every 1-2 hours. If one had coded or observed too long it wouldn''t have felt equal. And being equal and respecting the other fellow is necessary for successful PP, IMO. (This starts sounding like a dating for dummies guide but, after all, a great deal of PP is human interaction and most human interaction is similar)

I noticed that it isn''t very beneficial to try to pressure on a minor point too much. Often I felt that some things could''ve been done slightly differently ("in my way" but not essentially better so I just kept my mouth shut and commented on more useful stuff instead. He did the same. The result was that we didn''t end up fighting about things that are arguable (matters of taste), but made only the changes that mattered and were generally considered good.

But I suppose pair programming isn''t for everyone. If you have a huge ego or are bad in dealing with other people, it won''t work regardless of your pair. And then it also needs a good pairing, people who are roughly equal in skill level and that respect each other. Respect is perhaps the single most essential thing to have, with both sides.

Share on other sites
quote:
Original post by SabreMan
(systematically torn apart)

Points taken...I respect you quite a bit SabreMan.

I don''t mean to make this into a bash-pair-programming fest, I''d like to hear positive experiences about it as well. I think the big problems at my current place are:
1. different status in company (intern vs. fulltime employee, a very new one, but still)
2. ego (mine)
3. reluctance to accept pair programming (probably mutual)
4. triviality of project (clean others code)

I need to check into the narcolepsy bit though, fairly serious, I just pass out in class sometimes when I''m bored.

Share on other sites
I just did a class project for a databases class with my friend, in a style that would qualify as pair programming. The project was to implement a B+ Tree. We''d take turns writing code, with the other commenting and pointing out bugs/mistakes. At design time we''d both suggest what we thought was good, and choose the best of the two(or compromise). We''re both at similar skill levels, and I must say it worked excellently - we both caught bugs that the other person wrote, and having another perspective on the design side also really helped. We finished the project in record time, and only had one thing to fix(where we didn''t read the spec thoroughly enough). We didn''t have any bugs that weren''t caught very easily with two pairs of eyes.

So that was very much a positive experience.

Share on other sites
With my junior project team, we sorta 3-person round-robin pair programmed. It did get boring sometimes, but that''s probably because we stayed up for 14 hours straight once the night before the midterm.

We swapped coder/watcher/thinker every 15 minutes or so... and since everyone knew what code we were working on, there wasn''t really a "what was I working on again?" problem. If someone forgot where a certain line of code was, the other two would be able to tell him.

For most of the independant sections of the project, we worked separately. The part that we XP''d on was the GUI, since it was the merging-point for all of our individual sections.

Share on other sites
quote:
Original post by antareus
I don''t mean to make this into a bash-pair-programming fest

Well, what you did wrong is epitomised in statements like You have one person programming and the other just watches''. Obviously, none of the literature describing XP / Pair Programming advocates that, so if it''s what is actually happening, then you are clearly not pair programming.

• how does/should PP work?

• when does/doesn''t PP work?

• how might PP benefit you and your team?

You might conclude that there are benefits to be had from pair programming, but your current team are unable to reap those benefits since they are culturally unsuited to pair programming, for example. That shouldn''t warrant writing off pair programming altogether.
quote:

I''d like to hear positive experiences about it as well. I think the big problems at my current place are:
1. different status in company (intern vs. fulltime employee, a very new one, but still)

There''s still benefit to be had in such a scenario. I''ve pair programmed with junior programmers and it depends on how proactive they are in the role. On the one hand, the junior member might ask why are you doing it in that way''. Having to externalise the reasons for a decision is good on a couple of counts: i) it means you have to actively reason about your decision, effectively you should be able to justify it; ii) the junior member is learning valuable knowledge, which could form part of a wider apprenticeship'' type scheme.

Going off on a tangent... I believe organistions need to support their interns and juniors in such a manner, but I don''t see much of that actually happening. What usually happens is they take them in, send them on a crummy several-week course, and then throw them into a project as an analyst-programmer'' or software engineer'' with very little support. And industry wonders why there''s such a shortage of good developers!
quote:

2. ego (mine)
3. reluctance to accept pair programming (probably mutual)

Many programmers are reluctant to trust other programmers. You have to do something about that yourself. Your own personal attitude might be caused in part by the general culture of an organisation or a team. There''s often not much you can do about that. Pair programming, and XP in particular, requires that you trust the other members of your team. That might mean the team needs to be hand-picked for the job.
quote:

4. triviality of project (clean others code)

Pair programming doesn''t mean that you spend each and every day sitting in a pair at a terminal. You use it when you can benefit from it. Perhaps you might have an heuristic which says we always use pair programming when writing production code'', which frees you up to carry out prototyping and experimentation in whatever manner suits you, and then you can bring lots of ideas to a pair programming session. Or maybe you only bother with pair programming for particular sections of a project. Or maybe you use it as a mentoring device, as I suggested above.
quote:

I need to check into the narcolepsy bit though, fairly serious, I just pass out in class sometimes when I''m bored.

Try going to bed earlier!

• Forum Statistics

• Total Topics
628730
• Total Posts
2984427

• 25
• 11
• 10
• 16
• 14