Topic: Xtreme Programming (XP) (Read 2137 times)

What other sources I've read that vnc is not great for remote pair programming. Too slow.

I emailed the author of that tool and he responded:

That link he sent me is very informative.

http://blog.tridgell.net/?p=111

Just found this tool:
http://code.google.com/p/partiwm/wiki/xpra
https://help.ubuntu.com/community/Xpra

GUI version of GNU screen. Can't wait to try it out.

EDIT: xpra works *really* well. Impressed.
Edit2: heh, couldn't find support for multiple attached users...

Yep, basically that. Not slave/master. Agreed with what you said.

It's like if one person writes something, then another can immediately correct you and continue, rather than getting hassled with a slow back and forth messaging. And it's easier to talk in code than on IRC.

I'm interested to see it working as a teaching tool also. In the summer I might have someone to try it out on.

I've been reading this,
http://codinghorror.com/blog/2006/07/separating-programming-sheep-from-non-programming-goats.html

Interesting read.

On a related note, I just tried gobby, and I think it would be perfect for this task. It's great to have what feels like a multi-user version of gedit on a windows box. And actually looking into this, it includes a chat window so you don't even need to keep irc open.

http://gobby.0x539.de/

Certainly works.

Yeah, I was the other party with genjix, very effective.

I think there is a lot of talk in this thread about master/apprentice coders, I think this would work well but thats not the only use cases(I don't think it was in our case, genjix correct me if I'm wrong).

My problem is I'm a slow developer, I think that I'm quite good at getting the overall picture, while at the same time able to get down into the details of code with no problems, I'm just slow when writing(genjix opinions on this, how would you describe our working roles in this exercise?).

I think more so than being master/apprentice style relationship, it allowed the both of us to get onto the same page very quickly. The communication, the feedback was instant, which made taking action on them really easy and fast. This turns into a kind of feedback loop of fast feedback->fast changes ->fast feedback..... until it's done.

We made a lot of progress on the command line client for the stock market, genjix was pretty much brought completely up to speed on 2-3 frameworks for the server and the server itself, he got me up to speed on bitcoind's json-rpc.

I think that one of the things that sped things up was that genjix was  pre-occupied with the implementation, the very small details, getting lines of code to work. While I was thinking about what needs to be done, whats better etc.

Genjix never had to take time out to stop and think "whats the best way to do this?" because I had already done that. Once he'd done one thing, I was ready to give him what we were to move onto next. He had nothing to interupt his flow.

I think pair programming over the net works, as long as both parties are capable, not nessisarily master/apprentice.

We used ssh+gnu screen+vim and irc which worked fine. I think gobby, ssh+gnu screen & irc would work great. If both parties have a good enough connection and a headset then skype would probably be able to replace irc for the better.

genjix, a more in depth analysis of your experience would be great.

I tried it today with someone over IRC (their connection wasn't good enough for Skype) and a shared screen session. Effective. They quickly got me synchronised and we worked wastelessly.

I was looking at xkcd and this one reminded me of this thread.

http://xkcd.com/844/

Notice that the requirements only change if you code well, rather than fast.
If you code fast enough then it is possible (I have heard) to finish a project before they change the spec and you have to start all over again.

Also, if you are working as a pair, when they introduce ridiculous specs, you can say "we are right and they are insane", rather than "I am right and they are insane", for a change.

yeah the OP was talking about in real life, but then as I looked into it I got excited at the idea of trying it on some free software projects I'm currently writing.

Oh, over the net...

I will be interested to see how that goes. I don't know if the human communication bandwidth will be high enough.

OK.

Can't wait to try this with another dev.

Here's what I imagine over the net:
Gobby or shared screen session + vim over SSH -X
Skype for voice chat

Shame there's nothing like gobby for vim or vim mode for gobby...

Well put. This describes my best experiences with pair programming. Pulled a few all-nighters and gotten through a few kilos of coffee in this way. And produced some solutions that prove that two heads can be better than one.

I have only occasionally had the opportunity to do pair programming, but I would choose it every time when the opportunity arises.

I have done it with two seats at one desk with one keyboard and monitor. We never "took turns" on any formal basis, but we were always sliding the keyboard back and forth to each other without any formality. I have also done it with two seats at a larger desk with two keyboards and monitors. With that setup, we would sometimes drift off into non-pair programming, but would come back together as a pair anytime someone said anything.

In my opinion the whole strength of pair programming has nothing to do with the coding itself. It's that you are constantly discussing things with each other. This boosts both people's skills, because everyone has strengths and weaknesses, and both people naturally learn from the other person's strengths. And it's much more productive than two people working separately, because both people tend to work at the productivity of the most efficient team member. Finally, it's much more interesting than solo programming. You never find your mind drifting off onto other matters.

So am I correct to say that:
- The experienced coder is bogged down.
- The inexperienced coder makes massive leaps to the level of the experienced coder.

Definitely keen to try this out.

Depends on a lot.
I have had good and bad experiences with this - and learned a lot.
It seems to work if you can keep things object oriented and compartmentalize the tasks based on the skill difference.
And have periods of going over with each other what you are doing and why. Actually the skills gap diminishes quickly.

The worst was me with my background in dbase and pascal working with someone who had been handed a VB project that was over-running - he brought me into the project to help identify why it was over-running and help with working on finishing it.
Turns out the problem was really that it was being done in VB - he was a really skilled guy, he had just been worn down by the insanity of it.
There is just so very much difference with the way that VB does stuff compared to how it represents doing it and how a programmer would expect it to work that you end up getting into this kind of never-ending work/wtf?/debug/drugs/attempted suicide/fail/work cycle.
With a pair of you doing it,  you end up forming the kind of bond that I imagine soldiers formed in WW1 in the trenches after having gone over the top and survived.

Haggy.

What are your experiences of pair programming when 1 person has significantly higher skill advantage than the other? Is it a good way to teach programming?

How does it work in practice? Do they take turns to code while the other watches? Doesn't seem very efficient... Is there a looser way to code in pairs?

I'm used to agile dev in general though, but am thinking whether I can use pair programming as a teaching tool by constructing shared projects. The usual teacher-student method is too dictatorial for my tastes.