Remote development mainly involves the same tasks and challenges as when you're sat in the same office, except that any communication issues can't be fixed by physically standing/sitting next to someone. Instead the tools we use have to support us in making the sure communication works.

These are the tools (and ways to use them) I've found most important when working as a distributed team. I've split them into Dev Tools - which covers things that are specific to software development and Comms Tools - which covers anything that makes the long distance communication easier.

Finally I've also talked in Reject Bin about some things we've tried which either didn't work or weren't as helpful as we hoped.

Dev Tools

Stuff I use (or have used) to get actual dev work done.

SVN - shared source control is absolutely essential. Don't try to lock it down, let the devs see and edit all the code. The history is there if you need to blame anyone and reverting works if it's all gone bad.

These days we'd use GIT, but our dev team and code pre-dates it. Actually the code pre-dates SVN, (god I hate SourceSafe!)

Fisheye and Crucible - Fisheye provides a way to browse SVN nicely and Crucible makes managing code reviews from SVN really easy. Both of these are open to all devs so we can see all code reviews and commits, which proves very handy to figure out what changed, when and why. It's especially helpful when commit and review comments link to Jiras. When the code is easy to see and review, it gets a lot more attention and get used and improved more frequently.

Jira - bug tracker we can all access, edit, update, admin. The particular workflow or rules are not that relevant (as long as they're not too restrictive), just having a shared bug/issue/feature tracker with open comments and some kind of status indication, version record and ideally links to SVN, Wiki and deployment/release store.

IDE - Any of the tools you use to actually write the code. In my opinion there are two key rules: The first to allow people to use whatever they prefer to write the code. Personally I use STS and Jedit together, some others on the team use Netbeans, Eclipse, SciTE, Notepad++, Textpad - I don't judge.

This also implies a second key rule - make sure the toolchain is not dependent on any IDE. Anyone should be able to get the code, edit it, build it, deploy it and test it, from their command line. Then they can pick whatever IDE or dev environment they like and arrange whatever pretty screens work for them, on top of that command line toolchain.

SSH/RDP - if you can't get onto the server, you can't use the server. If the server has to be Windows, that realistically means RDP. If it's a (ahem)proper server, that means SSH. Also, that means any server the dev team needs to access. For us the usual sticking point was getting to the test boxes; our IT guys always worked out a way through to all the boxes we needed, but they may have found it painful sometimes.

Comms Tools

Stuff I use (or have used) as part of being a remote team. If the previous section was "tools to move code around" this section is "tools to move words around". That includes talking to other developers and techies, as well as people in the non-technical teams.

Wiki - you need documentation, this is the simplest way to do it well, use it frequently. Yes, it's not perfect, yes it'll get ugly, but seriously, can you take a look at that huge shared drive of Word docs (or Sharepoint) and tell me that's working well for you?

It can also work well as a shared & permanent note taking system, help and tutorial pages, communal blog, and generally do duties for any kind of structured text & images you need to be easily accessible and updateable.

IM - Instant messenger chat rooms and personal messenging became our main route for everyday comms. Ensure the one you chose has persistent history, ability to paste images (screenshots) and (smallish) files, and you can easily enable/disable its various alerts. Ideally have some kind of presence indication that you can control (so you can tell people you're away/busy/whatever)

Sadly we ended up using Lync due to some grand IT plan. It's crap, avoid it as an IM tool if at all possible. Maybe it's voice features are great, we didn't have those. Jabber/Pidgin worked well for us before Lync was imposed from above. Slack or similar would probably be good too.

Email - ahh, good old email. It works, although you'll always find some people will need lessons in email etiquette and generally how to use the written word. But that's not a problem with the tool, that's a problem with people - they can be educated, eventually :-)

Use folders, use search, use rules. Set up useful mail groups. Set up your running apps to email the relevant group when they get upset. Try not to use it for pushing large amounts of attachments around.

Phone - "It's good to talk". Especially as a remotie, it's the best way to stay social as well as get all the important conversations to flow well. Get a decent headset, throw away the handset, set up speed dial buttons for the whole team if you can. Learn how to do concalls, and practice doing it. Oh and learn how to use the mute button and to tell when you are on mute.

Regular phone calls - carries on from the previous one. I've talked about this in other posts about remote working, but I'll repeat it again - make sure you talk to the people you're working with regularly and frequently. Make your phone easy and comfortable to use and use it both for informal chats and more formal conference calls. Get into some regular calling habits, either by setting up "meetings" at the same time every week (even if it's just two of you) or just agreeing some project/team schedule for group discussions.

VNC - a shared desktop and a long phone call (on comfy headsets!) does a fairly passable job for pair-programming. Combined with some way to throw files between us (email, IM, directory shares), it's fairly easy to sit down as a pair and work through whatever knotty design, code, or debug issue is causing problems.

Shared drives - another one that isn't sexy, high-tech and modern. But they do the job. If possible have a shared area per person (with some form of fair quota) which they can alter privacy settings on, plus a public shared area visible to everyone, which people can agree how to divvy up into subdirectories based on their requirements over time. Our IT team were good at managing quotas flexibly and in return we tried to prune whenever we were asked.

The Reject Bin

Webcams - I'm not particularly pretty and my office isn't amazing enough that people want to see it regularly either. Sadly the same is true of most of the people I've worked with too. Also, we mainly negotiate with computers rather than people. That means we're usually not too dependent on reading subtle face/body cues from others.

We have occasionally trialled webcams and video conference facilities, but never found them to be helpful enough to be worth the hassle for daily use. At the most basic level, if we're trying to make eye contact we're not looking at the code/diagram/document we're talking about.

Shared Whiteboards - again these just didn't seem to be as helpful as the tools mentioned above. Decent monitors, a shared VNC session and a phone call seems to do the job just as well.

However, if there was a bigger distributed team doing fairly big design meetings, I would definitely want to try these again.

Timesheets - possibly a contentious one for those used to 1970's factory floor management. We've found that project and line management could get enough information and confidence about the work by knowing we're on their project full/half/part/tiny time, with a brief weekly update when things are going well and maybe a daily update at crunch times or in periods of rapid context switching (i.e. when management need to sit down and sort out some priorities).

Timesheets proved to be mainly wasted time both in filling them in and crunching the numbers; no one enjoyed dealing with them and no one got anything particularly useful from them. The summary info they did provide could be got much faster and less painfully by just talking occasionally.

We knew the end was nigh for timesheets when we realised no one commented when we forgot to submit them. Eventually none of us had completed a timesheet for over 3 months. We started asking what the timesheets were being used for. A few months later we got a management response that they "weren't being used for project tracking". It became clear that absolutely no one was using the timesheets for anything at all, so they were quietly dropped.

Team Jamborees - The idea was that rather than having a few weeks each year where all the remoties migrate to the main office and spend a week working there doing the same work as usual, instead the remoties and office bods would all meet up somewhere else (i.e. a hotel with some conference facilities ) for a few days to get outside the normal work environment, doing team building, learning, presenting, brain-storming type stuff during the day and food, drink, fun type stuff in the evenings.

We did a few of these, and they worked fairly well, we all learnt stuff, reminded each other we were real humans, came back with new plans. But they just never seemed worthwhile enough to be worth the hassle. Most of us have families that we are used to seeing in the evenings, so spending time away, although appreciated, made life a little harder. Also our director objected to signing off on a "jamboree" and the act of coming up with a duller name rather dulled our enthusiasm.

So this is an odd one, it didn't work for our team in that particular environment, but I could imagine them being a very good idea in other situations.

Previous Post Next Post