Disparate results, joint challenges
Gary and Judith Olson start their famous paper “Distance Matters” with a quote from Arthur Mee: “If, as it is said to be not unlikely in the near future, the principle of sight is applied to the telephone as well as that of sound, earth will be in truth a paradise, and distance will lose its enchantment by being abolished altogether.” Alas, distance still persists, particularly in software development where global adoptions of the process have posited harder challenges than the apparent advantages distance-mitigating technology (such as video-conferencing) brought in.
In his paper (PDF) “Global Software Engineering: The Future of Socio-Technical Coordination,” Jim Herbsleb (one of the organizers of the FoCSD workshop, read here) wittingly points out that the distance factor is what makes global software development (GSD) different from the traditional, collocated processes. Given Crowston and Malone’s definition of coordination as managing interdependent components, Herbsleb hints at three main areas of GSD in need of coordination: software architecture, requirements, and tools. Software architecture is molded by coordination on top of the technical skills and imagination required from architects and developers. The major dependency here is between tasks. Managing task dependencies effectively implies effective coordination at the software architecture phase. Thus, this being hinted at as the main challenge, the question is how it can be fit with an organizational structure. That is, are there sufficient resources to manage such dependencies over the distance factor? Next, requirements require abundant communication. In turn, communication and coordination are connected via a feedback loop where one guides/improves the other, as Jorge Aranda points out in his PhD thesis. Finally, tools are the manifestations of coordination mechanisms (as far as it concerns the subset of tools pertaining coordination in GSD).
But I want to emphasize one crucial point: coordination tools are to be built and actuated if, and only if, they are designed on top of demonstrated coordination mechanisms. Otherwise, developers and other actors shall be reluctant to employ these tools if there is not clearly tackled use case. A satisficing number of tools should be provided to cope with the GSD process — an overwhelming number could lead to communication breakdowns and, thus, could negatively affect coordination.
The latter point clues at the best coordination practices in GSD. A multiplicity of interactions and communication channels could make the GSD process perplexing; however, judging from appearances may yield incorrect conclusions or premises to anticipate a wrong conclusion. A challenge Herbselb poses is exactly this: identifying best practices (“effective” he calls them) and making the GSD process compatible thus attenuating the effect of distance.
I am, nevertheless, not fully impressed when modern researchers, on top of talking about the future, forgo important aspects of human systems — we are complex entities with complex interactions; thus, every human system (including GSD systems) should be studied from the viewpoint of Complex Systems. There’s more to a complex system than communication and tools — there’s collective intelligence and self-organization. Understanding the power of the latter processes could provide useful insights to understand what “effective” (as in “effective coordination”) means…
