ONLamp.com
oreilly.comSafari Books Online.Conferences.

advertisement


Tools for Geographically Distributed Software Development

by Ryan Bagueros
05/17/2007

It used to be that software development happened inside a building, usually decked out with office-blue carpeting and fluorescent lighting. Important discussions would take place in impromptu face-to-face meetings by engineers constellated around a water cooler or a box of donuts. Spending any time outside of the office during work hours would mean falling behind because so much of the project communication was exclusively in-person. In the modern world, development teams are increasingly becoming geographically distributed. Some projects last their entire life-span without any of the developers ever meeting each other. Geographically distributed development (GDD) offers a number of rewards in efficiency and cost but there are also challenges in creating successful GDD teams. In this article, I'll review some of the technology and tools we use to get significant gains out of GDD, within the context of the challenges posed by GDD.

Our software teams are made up of people primarily living in San Francisco, California and Sao Paulo, Brazil, but we've had projects that included developers in Germany, Netherlands, Argentina, and Venezuela. The motivations that compel organizations to try GDD can include the cost savings involved with outsourcing and the ability to generate faster development cycles by experimenting with programming methodologies like XP. Or, perhaps, the project is free software and it just so happens that the volunteers are spread out across the world. For our project, we all met while working on and managing open source software projects and our processes evolved to meet the demands imposed by a group made up of people living far away from each other. It was later that we decided to leverage the cost and speed advantages in projects for paying clients.

The biggest risk that a GDD project faces is with its ability to effectively communicate internally. The reason that bosses want their developers in the office everyday is because that's a proven technique to build a tight, well-communicating team, which is a critical part of any project's success. GDD not only lacks face-to-face relationships but there are also language barriers which make it even more difficult. However, technology can help geographically dispersed teams achieve a level of communication as sophisticated as what develops when everyone sees each other everyday.

Two professors from Columbia University have studied this facet of GDD and their answer is CHIME (Columbia Hypermedia Immersion Environment), a 3D virtual world that represents the software project. Developers "walk around" interacting with other developers' avatars and project artifacts (like the list of milestones, for example). The goal here is to give the engineers a virtual office that will promote the same type of interpersonal relationships that make in-person communication so effective. However, in our experience, that same effect can be achieved with some of the most basic internet tools. The cornerstone of GDD for us is the Internet Relay Chat protocol. We've found that IRC is superior to instant messaging for long-distance development because it captures the same effect that CHIME is going for. IRC provides the developers with a space to have real-time conversations with whomever is online and interested in the topic. Other developers don't need to be there to get something out of the conversation as they can read it in the backlog when they return. It is possible to incorporate IRC into a work style such that its easy to always maintain a presence in the channel without exerting too much effort to be there. So, developers can jump in with an answer to a question that only they know and then jump right back into what they were doing. If the development team has successfully integrated IRC into their workflow, it can also provide advantages over the traditional office because in IRC, the water cooler conversation includes more people and is logged for posterity.

The communications format of IRC also provides the basis for confronting the language barrier challenge. The socially-acceptable pauses allowed in the IRC back-and-forth give developers the chance to rely on a suite of tools to help them learn a new language. There is no better way to learn a new language than by jumping into real-world conversations with native speakers. The developer can build an effective suite of tools by using free services on the internet. Generally, the suite should include an online dictionary for translating words as well as a tool to conjugate verbs and provide other grammar-oriented translation functions. For example, AltaVista's Babelfish or the Google Translation Tools are absolutely terrible when translating individual words and, therefore, entire paragraphs. For example, if you put in the word "bear," there is no way to tell AltaVista or Google whether you mean the forest animal or the verb. But those types of tools are useful for conjugating verbs or building prepositional phrases. So, an effective mix of a quality online dictionary and the translation tools are needed. It is very easy to get comfortable with these tools and become really quick at referencing them while not taking an abnormally long time to respond within the context of IRC. Several members of our team have become bilingual or multilingual just by using IRC and free internet language tools. Granted, language instructors will note that this approach focuses entirely too much on reading/writing and almost no time is spent on speaking/listening but written fluency will make spoken fluency much more attainable. And, more importantly for us, written communication will suffice in getting the developers to work together.

Creating a virtual office in IRC (or something similar) is only the foundation of a GDD team but one of the most important. It is safe to say that over the past years, often the office I went to everyday in IRC was more "real" than the physical offices I would go into at dot-com companies in the San Francisco Bay Area. And after six or seven years of working like this, I met my co-workers for the first time last year at a Developers Summit we organized in Sao Paulo, Brazil.

Pages: 1, 2

Next Pagearrow





Sponsored by: