I’ve come across a good new blog, Coding Horror, written by Jeff Atwood, one of the founders of one of my favorite coding sites, Stack Overflow.  In reading through some of the older posts, I came across one that is close to my heart which is on working remotely, or what we at Microsoft called “distributed development” (since we didn’t like the assumption that one side is “remote” and the other “central”).  During my last few years at Microsoft I worked on a team that had members in different geographies, and also did a bunch of work on collecting best practices for Microsoft development teams new to the practice.

At Microsoft, I used to say, “Redmond is Rome” – in other words, the heart and soul of the company is still centralized in Redmond, Washington.  Since Microsoft is obviously a global company, it has always had locations all around the world – but most of the offices are sales, marketing and consulting, not core product development.  That’s starting to change, though, with the rise of large development centers in Hyderabad, India; Beijing and Shanghai, China; Haifa, Israel; Dublin, Ireland; and here in the United States in Silicon Valley, Boston and North Carolina; there also is a center in Vancouver, British Columbia.  Due to acquisitions, there are also a number of smaller sites doing product development all around the world, including in Portugal, France, Singapore, Germany, Norway, and Switzerland.

All of this places the Redmond-based teams in the midst of the distributed development challenge – how do you effectively manage software projects when you can’t gather all the people in a room for a quick meeting?  Software, far more than other engineering disciplines, has long relied on informal communication methods (like hallway encounters) to solve problems, generate new ideas and communicate quick status.

Jeff’s post offers a number of good solutions, as does my former colleague, Eric Brechner.  While I was part of Engineering Excellence at Microsoft (a team focused on improving the internal engineering tools, processes and people) I collected best practices and case studies on an internal site we called “http://distdev”.  In this way, we helped teams new to distributed development learn the tips and tricks from their colleagues, as well as avoid common mistakes (e.g. we always schedule meetings at times convenient for the Redmond participants, and don’t bother adding a dial-in number or Live Meeting ID to allow people not in Redmond to attend.  Sometimes just moving a 4 PM meeting to 10 AM makes a huge difference for the remote participants – while not really inconveniencing the Redmond participants at all.  Another trick I’ve seen used where the time zone differences are particularly challenging is alternating who is inconvenienced – so during daylight-savings time in the U.S. we arrange meetings at times that are convenient for U.S. participants and inconvenient for our colleagues in India; during standard time in the U.S., Redmond participants would be inconvenienced as meetings would be held during normal working hours in Hyderabad.  This also has the advantage of getting both sides (not just one) to experience the pain.

Ultimately, though, the goal isn’t pain but gain.  Jeff’s and Eric’s posts referenced above have a number of good suggestions on how to achieve that.  These come down to just a few basic rules:

• Communicate, communicate, communicate.  Use all the tools available to you – IM, video chat, Skype, email, etc.  Remember that it is much easier for things to go off track for a longer time when people don’t informally run into each other all the time and have the opportunity to say, “You’re doing what??? I’m doing that!”  or “You’re doing what??  We cut that last week!”
• Virtual tools are no replacement for real relationships.  A friend once wrote a book on software development with a memorable rule: “Don’t flip the Bozo bit”, by which he meant, don’t assume your colleagues are fools.  It’s easier to do that when you’ve never met the colleagues face-to-face.  Travel has to be part of any successful distributed development effort and it should be both ways – so both sides develop the informal relationships that grease the wheels of getting things done and act as a brake on assumptions that the other person “doesn’t get it”.
• Follow the basic rules of distributed systems.   In technical solutions, we’ve learned that those things that need high-bandwidth communications should be physically adjacent (ideally in the same box), while those that can tolerate more latency can be further distributed physically.  The same rules apply to development teams.  So for instance it’s less ideal if the PM/designer and developer for a feature are physically remote – it can of course work, and there are many examples of it working, but it’s better if you have in each location a self-contained team of PM, dev and test (the typical Microsoft product development triad) working on a feature, while in another location you have a similar team working on a different feature.  Of course there is still communications required between these teams – but the higher-bandwidth communication is contained within one physical location.