Me and a Simone, both at the Software Craftsmanship mailing list, tried out an experiment in doing remote pair programming today.
NUnit
Since both of us are comfortable with C# and NUnit committing this first infrastructure-experiment to using that combination felt the right way to go.
GMail
To do this experiment we started by having gmail chat as a base for all other communication channels. Next step was to get audio working via Skype. Both of these tools worked hassle-free.
Skype
Then we turned our attention to desktop sharing. Simone had looked up some alternatives yesterday, and we tried out Teamviewer first.
Teamviewer
Teamviewer was fast and easy to use. But sadly the free edition just ended after ten minutes.
Sharedview
So we tried the free SharedView from Microsoft. This turned out to be too slow, with mouse movements showing up after about 0.5 to 1 seconds.
We gave up on the desktop sharing idea, and focused on a second approach. In that approach we share only the source files via googlecode. Googlecode uses SVN for source code sharing, and both me and Simone used TortoiseSVN to synch the files.
Googlecode
TortoiseSVN
I added Simone to one of my already existing projects to get going fast.
Then we took turns writing unit tests and production code, committing changes as we went along.
TDD Problems
All along we kept communicating via Skype.
We choose one of the smaller problems from the TDD-problems* site, the Template Engine.
Online stopwatch
To measure time we used online-stopwatch.
One problem was that I used Visual C# Express edition, while Simone used Visual Studio professional, and there were conflicts between .csproj/.sln file formats. We solved this issue by only doing edits in one file, so to avoid this hassle.
All in all we spent almost two hours trying these things out. It was not hassle-free, but that we didn’t expect either. It was an experiment. You can see some of the resulting code in two of the screenshots nearby.
View from my computer
Template engine class
We decided to try more another time. One idea is trying the gobby multi user editor, and maybe using python or ruby instead of C#.
* If you’d like to contribute to the TDD-problems site, please drop me or one of the other contributors a mail or leave a comment on this blog post.
Tags: programming, tdd, pairprogramming, software craftsmanship
Besök bloggosfären!
OlofB[eta] 
I’m not going to write a blog post about it, so here’s my take on it.
Skype works great. Our network connections were not extremely fast, but we both could hear very well each other and with no lag.
Sharedview is too slow. Teamviewer works fine but the free edition stops working after a few minutes.
Ping-pong pairing with source controlled files works fine, since one is writing the tests and the other makes them pass. Probably when not doing ping-pong using source control to share files would not be as good, and in either case seeing the other writing is probably the best way of pairing remotely.
Didn’t try Gobby but it might be cool. When working with Visual Studio projects there are many files involved, but probably using Gobby in conjunction with source control would let peers share only the file/s they’re working on.
Apart from the tools, I’ve enjoyed it. We didn’t write a lot of code but after a few minutes I was quite comfortable with the situation. We had some issues communicating since my English is not as fluent as Olof’s, but I think it ended up being a minor issue.
Yeah I enjoyed it too 🙂
Hope we can try out some other stuff next week. I’m interested in gobby especially: http://gobby.0x539.de/trac/
It has been brought to my attention that Teamviewer does not usually stop after some few minutes — it might simply have been some kind of glitch today. So we might revisit that desktop sharing program!
You might try yuuguu for desktop sharing. It works well for me.
Hi, guys!
Great experiment!
You definitely should look at this:
Thomas K. and I use ”Cola” within Eclipse for a real-time shared editing session
We’ve tried it few months before in our team using Python and Pydev plugin for Eclipse. Looked not so exciting as we expected but worth trying anyway.
Now, it’s your turn. 😉
Looking forward for your opinion about that.
Scott, Oleg:
Thanks for hints. Simone and I have tried once or twice more after the initial experiment, we’re still into Teamviewer, but it keeps disconnecting every now and then.
We’re discussing trying out multi-editor Gobby and maybe Python or Ruby some time in the future, since it we would get a slicker realtime experience. It matters more than at least I thought, how fast the keys you press show up onscreen. Guess it is psychological to an extent, but working with 0,5 second delay really tires me out.
Keep experimenting, we’ll do so 🙂
I work with a company in Costa Rica that did TDD with pathfinder a USA company that did outsource programming for fortune400 companines. We used at first skype but it started to give problems with wireless connections the first week, so we changed to wired connections. Then we started having problems seeing the paires in the USA some how it was not trasparent always. At times the connection broke sometimes specially during the srums where everyone outside had to connect to a public phone number and then to the corresponding extension and conference number. So we tried the internal pbx it was an all common Asterix pbx, that let us use the free SIP/ service software (an xlite can do the trick)
At that point we started to have problems with the firewall in the USA and the VPN most companies now a day have. The problem was in the USA base company and after 2 o 3 week the company catch up with the problem.
After that we were able to use for free, pairing and scrums the xlite client. We still had skype an alternative solution for IM and phone
We used the AIM pidgin client for IM and a special chat room from campfire.com this company provided the chat room where all the time was connected at all times. Some times IM services and phones could fail, this turn to be the most reliable media during the project. We could always relay on it specially during the initial times of the projects where any other media were tested for the first time.
The most important problem on remote pairing is that you are hiring personel with whom you have never worked before and they are new not only to the project but to the companies methodology. Most likely will not have full experience with TDD much less pairing, the full day. The gap in technology level is to be expected. The problems tends to be solved in my experience of several projects during the 3rd of 4th iteration working together. During that time the best thing to do is to fisically send programmers from the core team to the remote site. This will create a filling of team, understanding of the client needs and intimacy with the cultural gap between both groups, simple things as the possition of the desk of the programmers, see the ages, personalities, going out for a dinner night or 2 will increase productivity to the top.
One thing this days of crisis is to take in account that clients are only paying for what they see. The external productivity (the points of the stories). Be very consient as a project manager to keep an eye on the points every and each resource is producing. Some time remote members tend to relay on other to do the work for them, produce nothing. Other tend to relay on the other side totally on the external productivity, the points, other tend to relay heavylly on the internal productivity (refactoring). Be very consient that on this days the new resources the client pays should increase points done. Some time to do things more productive is to start working on the critical path tasks, Detect the buttlenecks at the beginning of the iteration and work on them with the tech lead of the project and a very points oriented programmer.
I ll personally will try to set team buy orientation. Some programmers the more technically oriented by nature will focus on refactoring and creation of new features. This will at the beginning should be part of the core group. And the more point oriented ones should be the remote ones. The reason is that teams will start subconsient or concientlly trusting the people they already know as teck sabies, an thats ok and important to recognize. The easier way to manage remote resources is by objectives clear and crisp (Points that is) they know what their goal is and will not have the bad feeling that something could be wrong and not know it. They most likely wont know someting is wrong until to late, no matter how much he ask for information. Remember remote paring is for production increase and at the bigging this is only objective on the external points not the internal ones that are more subject to the eyes of the beholder
any questions can call joseluis.segura@gmail.com
Ah we also used vnc at the beginning an then change to teamviewer. Faster and free for trial purposes.
The svn was use for the flex, grails, jms, c# and scripts source management
as a conclution I will recomend pairing on both sides and across. But focus the remote resoucrs on the Points Productivity (because this is more objective) and the locals on the refactoring becouse of the subjective reasons and trust
Joe; thanks for your thorough experience sharing, many interesting insights. The world will be a better place of more people share instead of keep things for themselves 😉
Hello!! We are working on this. You can use [www.beWeeVee.com][1] by now as a workaround. Meanwhile we are working on this: [http://www.youtube.com/watch?v=DwXNk-lCIdg][2]
We’ll welcome your feedback!!
Thanks in advance!
[1]: http://www.beWeeVee.com
[2]: http://www.youtube.com/watch?v=DwXNk-lCIdg
Sebastian – thanks for these tips. Me and Simone might just try these out! It sure does look interesting.
Hello,
We have develop a Remote Pair Programming AddIn for Visual Studio, you should try it, is not a concept, it is a real Remote Collaboration Platform.
Is going to be in the market next month (March 2008), now there is a pre-release available you can download at http://www.wave-vs.net
It supports Core IDE editors sharing and designers like Components/Forms/User Controls and others….
For a complete list of features is better to take a look on product pages, as we are adding new features practically every week…..
Jesus
bye
Where I say 2008 I wanted to say 2010 ;), sorry me 😀
Product is going to be available on March – 2010
bye!
I would like to suggest another alternative to this – RHUB remote access. It is capable of connecting to lock down systems. With RHUB appliance, you can connect up to 1000 PCs, remotely lock, reboot, or send Ctl+Alt+Del to your remote PC.There are a host of other features, which enable you to completely control your remote system.
I’d like to thank all giving hints on new tooling for this kind of remote pair programming. I might re-visit the topic in the future, and then I have some starting points for free 😉
You should give Proxy Networks a look. Check out their free demo (lasts much longer than ten minutes!) and tell me it doesn’t surpass TeamViewer. I have tried almost all of the options out there and Proxy come out at or near the top in just about all of my personal usability criteria.
This is a good tip especially to those fresh to the blogosphere.
Simple but very precise info… Thanks for sharing
this one. A must read post!
Why viewers still make use of to read news papers when in this
technological globe the whole thing is presented on net?