Remote Development Panel, Dan Antion (chair), Avi Bryant, David Buck, James Foster, David Pennington, Terry Raymond, Niall Ross
As I was in the panel, I recorded others' points as best I could and my own not at all. Thus mine are added post-hoc from memory (and probably read more eloquently than they sounded at the time :-)). Dan thought design tasks were more difficult to do remotely than development tasks. He asked each of us to summarise our remote working experience. Thereafter, Dan introduced topics and we gave our views on them.
David Buck (Simberon]): had a smalltalk developer at a remote site (i.e. his home) and needed to share code while writing Elastolab. (Also in POV-Ray project, remote experience managing source code). Remote end-users are hard since you need feedback (Chicago to Atlanta end-user was hard).
James Foster: two years ago, he was doing healthcare Smalltalk work. The company asked him to move which he refused. Instead he and colleagues got hired by an Atlanta company while working in Fargo North Dakota (which is pretty remote :-)). His experience is that a development team can be distributed. All his customers tend to be remote (e.g. hospitals in 17 states) so when he became a remote developer there was no change in that.
Conventional wisdom is that you must partition tasks and give some to the remote office. By contrast, they have been much more integrated into the overall team. James spends more time talking to people in Atlanta than to people in Fargo; they have intentionally arranged the tasks that way.
The Corporate Datacentre in Atlanta is half-an-hour from the main office in Atlanta; they're remote anyway :-).
Avi Bryant: does much remote Squeak consulting. His clients need source control systems for Squeak and he also pair-programs with them in Squeak, plus he participates in the Squeak open source activities which are usually remote. The open source world has large projects, e.g. Squeak has 50 people working on bits of it (OK that's unusual). Real design discussions take an hour face-to-face or a few days of emails; the chronology, not effort, can change significantly.
Niall Ross (eXtremeMetaProgrammers): mid-90's, I ran a team which at one point needed a particular combination of skills (Prolog as well as Smalltalk, etc.) which we could only source in someone who had to live 200 miles away. Most reluctantly, my then employer accepted hiring this chap to be on-site for two (consecutive) days in every fortnight, otherwise working remotely. He
- had to learn how to work remotely
- had to teach me how to run a split local / remote team
It was a very useful experience and I've built on it over the years. If I had to name one thing (as the panel progresses I'll mention several), it would be Keyboard-Video-Mouse-sharing tools. We started with NetMeeting (which I still like) and I have also used SameTime (Lotus notes add-on), pcAnywhere (not so good for this) and (recently) Citrix. I have provided a write-up of a remote pair-programming session using KVM-sharing which (I assume) will appear with the conference slides and papers on the web.
David Pennington (TotallyObjects): Dave runs the ultimate remote company as they are in the UK but 97% of business is international (mostly in the U.S. but he has also had customers in Sweden, etc.). Dave has been working remotely for Dan Antion's group for three years. He met Dan for the first time at a conference last year and has met him for the second time on this panel. Biggest remote working problems are hardware; 'It doesn't work on AIX connected to IBM' but TotallyObjects have neither machine so cannot reproduce error. Client uses Oracle, so TotallyObjects must grapple with installing Oracle. Dave noted the possibly advantages of KVM-sharing with his major clients, but if a client has only bought a 100 pound utility from TO then they will not arranged any KVM-sharing with TO.
Time zones are another issue. They work with clients in New Zealand; forget to send that last email of the day and you've lost an entire day in getting an issue resolved. Public holidays can delay you similarly because, "Oh yes, it's the fourth of July over there". He can talk end up talking on the phone late from home and thinking the next day, "Just what did I say to them after finishing that bottle of wine circa 23:00?"
A Swedish client just specified a DB problem and let TO solve it, which worked well. Had the client sought more detailed control, that would have made remote working much harder.
David Buck's pair worked one day on Elastolab each week, whereas David was working at a day job and on Elastolab in the evenings, so it was hard to coordinate. If his pair got stuck at 09:00, he stayed stuck till David was free. He found that remote working needed extra documentation, e.g. design documentation so his pair could read it when he was not there, and also standard processes (start up, etc.) had to be documented. This could be seen as an advantage.
Niall and Avi both commented on the advantage that more things get captured when you are working remotely. Avi found it helpful that a design discussion carried on by email let you revisit those emails to see who said what and why. Niall noted that if a diagram was needed to illustrate some code or design idea, it had to be drawn in a tool (Visio was the one we often used) instead of on a whiteboard, so was available to look at later.
James pointed out that time difference and space difference are not related. On a typical site, some people come in at 07:00, others at 10:00, so a degree of time-zone separation can be compensated for by different start-times and/or seen as another example of them. Only when the gap grows large is remote working creating a new issue. Terry Raymond (Crafted Smalltalk) in U.S. works for Soops in Holland. He starts work at 06:00 (noon their time) and uses IRC and email but not (yet) KVM-sharing tools.
Security rules can make problems for remote working. James' customers are hospitals and some believe they cannot show vendors any of their data so it is, "describe your screen please" when he is trying to fix problems for them. A KVM-sharing tool would be blocked by this requirement.
Face time: David and Dan worked with very little face time (met last year and at this conference). David noted that the first meeting with a customer after three years of working for him can be terrifying. Having met up, they use AOL instant messenger more and David is readier to pick the phone up to Dan than before he met him. Dan is the only one of David's regular programming clients whom he has ever met (he's met some who've bought his software at StSs) Niall said that remote XP is very doable provided you have met (and occasionally re-meet) the people with whom you remotely pair-program. I think it important to have their face in your mind and some knowledge of their temperament, but noted David and Dan's experience; this need could itself be a matter of temperament, theirs and yours. James, like Niall, has always had the pre-existing relation. However you can get to 'know' someone from a blog or frequent posting on newsgroups. Terry visits Soops in Holland every two months for a week. The visits really help.
Next, Dan raised the question of configuration management. In Smalltalk, you need to pass code to your co-workers and sometimes need to pass your helper classes that live in your development image and enable what you're sending them.
Squeak's lack of a good version control system was a problem for remote development. Avi has worked on this. Nebraska is Squeak's KVM tool: it is very good and allows everyone connected to have their own cursor.
Niall found Envy quite good for export-import but hopeless for remote access due to its very chatty protocol. His team always ensured the KVM-tool shared an image that was local to its Envy. Because Niall had been in the habit of talking work home at weekends for years before the team began KVM-enabled pair programming, a process for how code could be worked on in local repositories and reintegrated with the master had already been worked out. It is straightforward to work out such a process (e.g. naming conventions that allow tracking of who changed things and from what base) but important to do so. My limited experience of Store suggests it will also be good, and better for working remotely from the repository ('better' here means viable; Envy was not viable). As regards the KVM-sharing itself, early Java-Swing conflicted with NetMeeting; Niall has not seen any other problems. James has found VA/Envy doable.
Usually, the client supplies any code TotallyObjects needs to do the work. When TotallyObjects sell their tools on the web, they make new releases only every year and a half, so purchasers find reloading and reintegrating acceptable. However TotallyObjects have to make loading their tool releases easy because those clients that they supply to directly may get a new release once every two weeks. Backward compatibility is similar.
David Buck found source code management the easiest problem to solve. Store in VW is designed for remote development. Postgres was easily internet accessible; no problem. His practice was to define an interface and then asks his co-worker to implement it; this avoided code clashes.
Soops publish and merge 3-4 times a day and Terry merges in the same way the others do. Cincom people try to avoid treading on each others' toes so have few merge problems. Niall found that the merging process was much the same as the local one because the remote person often pair-programmed with a local person by sharing the latter's machine, so the code was in the latter's view of the repository anyway.
Niall was asked to describe his KVM-sharing pair-programming process in detail (see Niall's paper for an example). The first need we found was for everyone in the team to have a headphone set for their telephones. These are cheap (tens of pounds) and make an immense difference to the ease of the process. Non-headset handsfree phones pick up too much background noise (especially from the machine, which they will be near) and also cause it (bad when several people in a bay are all working this way). Ordinary phones quickly cause neck-ache.
Using the computer to send the voice instead of a phone-line is possible and with ADSL and upward may be feasible. However good voice quality and rapid remote response are important. Only Smalltalk-specific tools like Tukan / Coast can work with 64k or less for the KVM-sharing. NetMeeting and pcAnywhere must have 100K+ (so ISDN is OK) for the KVM-sharing (I've been told VNC needs even more), so you must use a phone-line for the voice unless you have ADSL or better connection. Another significant motive for using a phone-line for voice is that if the weblink is lost, freezes or falls behind, the voicelink lets you discover and remedy it. The only motive for using the computer to send the voice, but it can be a compelling one, is cost. (SpeakFreely and picoPhone are good IP telephony tools.)
Easy swapping of control (either by having two cursors or by NetMeeting's double-click-to-take-control feature) is essential; pcAnywhere lacks this. I also like being able to share just the application I want, not the whole screen, and having the shared screen in an overall window that I can minimise. Again, this favours NetMeeting and SameTime over pcAnywhere (I've yet to explore the range of configurations Citrix offers).
A final point that took us by surprise but has been a great discovery is that KVM-sharing is also the best way to do pair-programming when you are not remote. If two (and sometimes it is three or more) people cluster around a single screen at a single desk then the screen, mouse and keyboard are (at best) at the right distance and angle for one of them, so that one becomes the principal programmer and the other is marginalised. This effect is enhanced if the machine belongs to the nearer programmer, as is often the case. Once we became fluent in KVM-sharing, we gradually realised that two people could sit at adjacent desks, share KVM and work exactly as if remote, except that, being in easy talking distance, they did not of course need to put on their phone headsets. This was an easier way to work. Each person could login as themselves on their own machine, see their own environment, have keyboard monitor and mouse at the right distance for them, and then share the Smalltalk IDE and pair-program. I now work like this routinely and find that people who pair with me soon get used to it and find they like it. It also improves remote working since local and remote pairing now feel much the same and use the same tools (except the phone).
James noted that pcAnywhere was designed for remote support, not shared working, and was not good at the latter. NetMeeting is windows-ubiquitous (but it does not work over a Cisco VPN). Citrix is good and may well be already present in related activities the client is doing.
Lastly, Dan asked how we should justify remote working to management.
James: remote development is bad but the alternatives are worse. If someone good is moving, remote working may let you keep them. If a deadline has to be met, remote working may let you meet it. Arranging to work in the same site may just be too costly. Niall agreed. I once had a sudden deadline dropped on my team just before the Easter weekend. Getting the team to work on-site for four holiday days would have been impossible as regards our families and pre-arranged activities. By contrast, pair programming from home for selected hours was possible and thanks to it we met the deadline and won considerable applause. Someone quoted Sir Winston Churchill, "Democracy is the worst form of government - except for all the other forms." Remote working has its drawbacks but it may still be by far the most cost-effective solution to the problem of getting the right people working together in the right groups at the right times.
Dan will put his notes on www.nuclearInsurance.com/ftp.
Previous Topic
