Between outsourcing and flextime, virtual development teams are fast becoming the rule rather than the exception. But can team members work together when they're so far apart? Read two stories of how real-life programmers are making it work.
Simply Communicate by Dave Thomas and Andy Hunt
Software development is a process based primarily on communication. Developers communicate with customers, testers communicate with developers, team members communicate with each other and their managers, and everyone communicates with the computers. If you look at a team that produces exceptional products, you'll find a group that has learned to communicate exceptionally well.
The most effective form of communication is face-to-face, which is why many of the agile methodologies, such as Extreme Programming (XP), require that development teams and even their customers be co-located. But the real world is not co-located. It spans buildings, states, and even hemispheres, and so do our teams. A geographically divided team makes communication more difficult. Email and telephones have limited bandwidth, and misunderstandings can become commonplace. How do teams successfully manage these problems?
We can't speak for the whole world of software development, but we can describe the tools and techniques that we personally use when working remotely. In the past nine years, we’ve jointly written five books, countless articles, and literally millions of lines of code for ourselves and for our clients, all while working remotely. Andy lives in North Carolina, Dave lives in Texas, and our clients are all over the map.
It Takes a Dungeon
We first met while working on a pressure cooker of a project: A credit card services company needed to create a new communications switch against a tight (aka "impossible") deadline.
We started the project on site, using an ex-storage room for an office. It was a tiny space, with no windows, in a hot climate (with an air conditioning system that apparently enjoyed independent thought). The two of us worked twelve hour days for three months, churning out over 250,000 lines of C code in the process. During that time, we learned to communicate with each other in a very abbreviated but content-rich manner.
We came up with a whole set of shared stories and metaphors as a kind of shorthand that increased the effectiveness of our communication. It's like the old joke about the prison inmates: They know all the jokes so well, they don't bother telling the jokes anymore; they just refer to them by number: "Number 75!" one calls out, and everyone laughs.
Early in the project, we met a developer who wasted an entire month refusing to accept that he had a problem with his code. Instead, he blamed the select system call of the operating system. The operating system was functioning just fine, of course, but his dogged refusal to admit that he was at fault was a perfect exemplar of our own occasional unwillingness to accept the facts. The memory of this shared experience conveys a powerful message of humility in just a single, significant word: like the prisoners, one of us just says "select," and the other immediately breaks out of a blame-game rut.
Shared meaning, expressed concisely, is a cornerstone of effective communication. With this firm foundation in place, we were then able to work remotely for the remainder of the project.
It Takes Some Technology, Too
When working remotely, we try hard to make it seem as if we are in the same room. We both use wireless phones with headsets, so a conversation is never more than a single button-push away. We normally have lots of short, 30-second calls interspersed with longer, deeper discussions. These brief, spur-of-the-moment calls are crucial to keeping a shared context alive. Without them, communication tends to get increasingly formal and less effective. We also use email, wikis, and shared weblogs to communicate.