Telecommuting for software developers

I telecommute a lot, and it's a pretty extreme case of telecommuting as well: I'm based in New Zealand, while my clients usually are in North America, Europe or Asia. Occasionally I meet some of them in person, but often I never get a chance to shake their hands. In this article here I want to talk a little about how I tend to make telecommuting work for me and my clients.

Telecommuting and modern development processes: A conflict?

While telecommuting has become much more acceptable in the last few years, many prospective clients or employers still shy away from it. Their concerns are understandable: How can someone so far away be successfully integrated into a team? How can that person really participate in the development process, brain-storming or design sessions, code reviews or high-pressure debugging sessions?

In fact, there are two opposing trends at work here: On one hand we have more and better technology available for telecommuting. On the other hand, however, the more we talk about iterative and agile processes in software development, the more it is felt that in-office presence is required, since these processes rely on low-latency, high-bandwidth and frequent communication.

The question then for every telecommuter and their employer/client is this: How can we best adapt the way we work and utilize available technology to make telecommuting work even with the small-team, interactive and iterative, communication-heavy approach that is often preferred today?

Making telecommuting work requires some preparation and a little bit of flexibility from both sides. Undoubtedly, there are a lot of nuances, which you will miss out on, no matter how good the tele-presence technology at your disposal might be. I'm not saying that you can make telecommuting 100% equivalent to on-site presence. However, I do believe that telecommuting can be made to work very efficiently, and usually much more so than most people would guess.

In fact, I have telecommuted not only as a developer, but even as the engineering manager of teams, doing everything from architecture and design to the daily ins and outs of project management. It can work, and it can work well if both sides are willing to work together.

Here now a list of my favourite tools, methods and infrastructure components, which help a telecommuting software developer to integrate and work well with a team.

Almost like being there in person

Let me address some of the key concerns I hear a lot. For each of these concerns I try to suggest a solution.

• Concern: "We have testing/development/documentation resources in our network. A telecommuter doesn't have all of this available and thus cannot be effective."
  
  Access to important development resources, such as build-servers, test-databases, in-house wikis and other services can easily be provided through a VPN (Virtual Private Network). Good open-source VPN software is available, so aside from the initial setup work, cost should not be a concern. OpenVPN is popular and is available in the standard repos for most Linux distributions. It can be downloaded for Windows, or in its source form here.
  
  In many cases, shared resourced like this can also be hosted 'in the cloud', or simply as a cheap VPS. Properly secured with SSH keys and logins for each developer it will do just fine. Wikis, test suites, databases, and so on can be hosted there.
  
  Very important, of course, is the use of a version control system. There are some VCSs now specifically designed for distributed teams, for example Git. But I have also worked successfully for clients that used SVN, even though our team was distributed. If you are not dealing with projects the size of the Linux kernel and also have a relatively small team, you won't have to convert your project to a new VCS, the old one most likely will do just fine.
  

• Concern: "In an office, people can just pop their head over the cubicle wall to ask a quick question. With telecommuting there is a lot of communication overhead and long turn-around time."
  
  Fortunately, that's why we have instant messaging. A plethora of IM clients is available for free and most everyone these days has an account with at least one of them somewhere. Quickly typing a question is just as effective as 'popping their head over the cubicle wall', and possibly less distracting.
  
  In addition there is always the phone and VoIP (see next paragraph for more on that).
  
  
• Concern: "With the team in the same office they all see each other on a daily basis. Because of that they have a more personal, closer relationship and form a better team."
  
  I can't say that presence in the same office always makes for good relationships, but I understand the concern. Luckily, for a few years already, we have a service available to us which solves this problem, again for free. Of course, I'm talking about Skype, which offers voice, chat and video conferencing. Personally, I would much prefer a capable open-source solution, but time and again Skype's painless setup and ease-of-use has proven just too simple and effective to argue with.
  
  Whichever route you go: Seeing each others' faces and hearing their voices on a daily basis is not a problem anymore these days. The services are free, run on Windows, Linux and Macs and web-cams are cheap.
  
  
• Concern: "We often have brain-storming sessions or our daily scrum standup meeting in the conference room..."
  
  The easiest solution is to place a laptop with a web-cam in the conference room. Even something cheap like an Asus EEE PC will do. No, I'm serious! I have worked in teams where we did exactly that. We had a laptop in the conference room and a web-cam. The laptop was useful for occasional presentations anyway, and I was able to 'be there' during discussions and meetings.
  
  
• Concern: "How can a code-review meeting be conducted? Don't tell me you can read the code that's projected on the wall when 'being present' via a web-cam from the other side of the room..."
  
  There are some really nice tools available for code-reviews in distributed teams. For example CodeStriker, which is simple but very effective. It's open source, so again it's free. Sure, that's not a meeting where everyone piles into the same room, but having experienced both types of code review, I can attest to the fact that a code review via CodeStriker is much more pleasant than a sleep-inducing code review meeting with everyone in the same room.
  
  
• Concern: "We do a lot of pair-programming / pair-debug-sessions. That's just not possible in a distributed team."
  
  Of course it is! There might even be specialized tools available for this. However, the simplest one I have found is straight-forward screen sharing. VNC is the usual, free and open source standard. But there are also commercial screen-sharing services, such as GoToMeeting.com. You start a Skype session or phone call (voice is sufficient here) with each other and then one of the pair shares their screen with the other one. You can even set up VNC so that you can control the screen remotely, allowing you to 'grab the mouse' and point at something you are talking about.
  
  A number of free and/or open-source VNC clients and servers are available or are already in the standard repos for most Linux distributions. In Ubuntu, for example, screen-sharing comes pre-installed already. You just chose 'Remote Desktop' from your preferences, or 'Remote Desktop Viewer' from your Internet applications. That's how simple it is these days.
  
  Obviously, this is made easier when a VPN has been setup, since otherwise you need to figure out how to get the necessary network traffic through your firewall(s).
  
  Even simpler than VNC is just a plain old 'screen' session in a terminal. That works great on any *nix server to which one or more team member can login to. The big advantage of a shared 'screen' session is that it has much lower bandwidth requirements than VNC and thus works better for any shared work that only requires textual information.
  
  
• Concern: "We need to be able to collaborate in real time on notes/documents/drawings. In short: We need a whiteboard!"
  
  There are several solutions I am using for this. One very effective and simple one is EtherPad, which is a straight-forward way for multiple people to simultaneously collaborate on the same document. You actually see the individual letters appear as the other person types, contributions from different people are color coded and you have a time-slider at the top to re-visit the evolution of the document. You can also export the documents as PDF or Word file.
  
  For diagrams and drawings, Creately offers similar features. Just like EtherPad, you can get started for free. Of course, there are a number of similar offerings out there, EtherPad and Creately are not the only one.
  
  In fact, remember what I said about pair-programming, using VNC? You can take the same approach for diagramming and sketches, allowing you to simultaneously work on the same drawing application (Visio or the drawing functionality in most presentation of word-processing packages).
  
  
• Concern: "We use Post-It notes for our Scrum board..."
  
  Online Scrum boards are offered by more than one provider. Scrumy is one of those services, giving you the 'look and feel' of Post-It notes. Many people still like to represent their Scrum board in spreadsheets or Wikis, though.
  
  
• Concern: "All these technical solutions are fragile or take too long to set up when you need them."
  
  The best advise I can give here is to prepare ahead of time. When you start your telecommuting workday, make sure nothing has 'fallen over' and you can still connect via the VPN. If you have a fickle sound system on your desktop then make a Skype test call (for example) to confirm that it all still works. Make sure to have a how-to on the company wiki that explains the use of VNC or whichever other screen-sharing service you use and occasionally go with your colleagues through a test session at least. Always send any visuals or supporting documentation out to all meeting attendees sufficiently ahead of the actual meeting.
  
  
• Concern: "You are in a completely different time-zone, so even with all those communication tools, you still won't be able to interact with the team."
  
  Addressing this concern requires a bit of flexibility by the telecommuting worker. Most work environments, especially for software development, won't be strictly 9 to 5. Instead, they may have 'core hours' (10 am to 3 pm, for example). It helps when you as the telecommuter can offer the client/employer that you will at least be at your computer during those core hours they have in their office, no matter which time-zone you are in.
  
  Case in point: When I work for clients on the US west-coast, I tend to get up around 4:30 am, which is about the time the team there gets into the office in the morning. I also arranged my work week to go from Tuesdays through Saturdays, in order to compensate for the one day that New Zealand is ahead of the US.
  
  As a telecommuter we ask for some flexibility from the client, therefore we can offer this much flexibility in return.
  
  
• Concern: "When a team is housed in the same office you get valuable informal interactions, watercooler talk, which you just can't get when telecommuting.
  
  Indeed, this is one of the toughest things to deal with. Short of roaming the corridors with one of these (a bit pricey), or these (somewhat cheaper), the best solution appears to be to (a) take full advantage of all the other means of communication, (b) encourage the team to involve the telecommuting worker(s) when the discussion turns to work-related issues and (c) to install a thin laptop/desktop in the kitchen or other common gathering area as well, start Skype and set it to auto-answer, which allows the telecommuter to 'visit' that area whenever they want to.
  
  The cheapest and probably most effective solution, however, is to continually keep the team as well as the telecommuting worker in mind. It is easy to 'forget' about the other side at times. Staying in contact can take a little bit of effort if you are engrossed in a programming task, for example. Occasionally, it is good to make a point out of calling someone else, rather than 'just' sending an email or IM, efficient as those solutions may be.
  

So much for my thoughts on this. Hopefully this list can help you or your clients to consider telecommuting as a valid option. If you have any additional ideas or suggestions how to enable a telecommuting software developer, please let me know in the comments.

Oh, and by the way, you should follow me on twitter here.