Vivek Haldar

Research Roundup: Programming and Remote Teams

In no particular order, brief summaries of some papers I’ve been reading lately on the topic of programming and distributed/remote teams. Note that this is not opinion, but backed up by empirical data.

I’d love to hear of any other good references on the topic.

  • “Conventional wisdom … holds that distributed software development is riskier and more challenging than collocated development… [We compare] the post-release failures of components that were developed in a distributed fashion with those that were developed by collocated teams. We found a negligible difference in failures. This difference becomes even less significant when controlling for the number of developers working on a binary. Furthermore, we also found that component characteristics (such as code churn, complexity, dependency information, and test code coverage) differ very little between distributed and collocated components.” The paper goes on to detail some of the practices that contributed to making this difference small. Among other things, “developers made heavy use of synchronous communication daily. Employees took on the responsibility of staying at work late or arriving early for a status conference call on a rotating basis, changing the site that needed to keep odd hours every week. Keeping in close and frequent contact increases the level of awareness and the feeling of ‘teamness’. This also helps to convey status and resolve issues quickly before they escalate. In addition, Engineers also regularly traveled between remote sites during development for important meetings.” 1
  • A decade ago, distance mattered, a lot. In spite of that, since then, distributed work has only grown, fueled by both economic and other considerations (e.g. the talent may not be where you want them to be). A range of technologies has made this easier: shared documents and calendars, instant messaging, video conferencing over the net; but also a realization that distributed, virtual leadership is a distinct and valuable skill. 2
  • Distributed development was “considered harmful”, but recent rechecking of those results has revealed that “the effect size of the differences seen in the collocated and distributed software was so small that it need not concern industrial practitioners. Our conclusion is that … distributed development is not considered harmful.” 3
  • Among the behaviors that have the biggest impact on effectively working remotely: communicating changes and status to downstream dependencies, clear communication of who owns what, responsiveness to emails and IMs, and co-operation (which means actually helping and unblocking someone). 4

(All emphasis mine.)

  1. Does Distributed Development Affect Software Quality? An Empirical Case Study of Windows Vista. Christian Bird, Nachiappan Nagappan, Premkumar Devanbu, Harald Gall, and Brendan Murphy. May 2009. ↩︎

  2. What Still Matters about Distance?Gary M. Olson, Judith S. Olson, and Gina Venolia. February 2009 ↩︎

  3. Distributed Development Considered Harmful?Ekrem Kocaguneli, Thomas Zimmermann, Christian Bird, Nachiappan Nagappan, and Tim Menzies. May 2013 ↩︎

  4. Coordination in Large-Scale Software Development: Helpful and Unhelpful Behaviors. Andrew Begel and Nachiappan Nagappan. 28 September 2009 ↩︎