, Lucent Technologies
, Lucent Technologies
Pages: pp. 16-20
The last several decades have witnessed a steady, irreversible trend toward the globalization of business, and of software-intensive high-technology businesses in particular. Economic forces are relentlessly turning national markets into global markets and spawning new forms of competition and cooperation that reach across national boundaries. This change is having a profound impact not only on marketing and distribution but also on the way products are conceived, designed, constructed, tested, and delivered to customers. 1
Software engineers have recognized the profound influence of business globalization for some time, generating alarmist reactions in some quarters and moving others to try to capture and emulate models that have met with success. More recently, attention has turned toward trying to understand the factors that enable multinationals and virtual corporations to operate successfully across geographic and cultural boundaries.
Over the last few years, software has become a vital component of almost every business. Success increasingly depends on using software as a competitive weapon. More than a decade ago, seeking lower costs and access to skilled resources, many organizations began to experiment with remotely located software development facilities and with outsourcing. Several factors have accelerated this trend:
As a result, software development is increasingly a multisite, multicultural, globally distributed undertaking. Engineers, managers, and executives face numerous, formidable challenges on many levels, from the technical to the social and cultural.
Is working at a distance really such a problem? Nearly everyone with GSD experience, it seems, has anecdotes illustrating difficulties and misunderstandings. While these stories are compelling, they do not give us a clear picture of its cumulative effects. However, we have strong evidence, 2 based both on statistical modeling of development interval and on survey results, that multisite development tasks take much longer than comparable colocated tasks and that communication and coordination play major roles in this delay.
While we focus primarily on the problems of GSD, we should not neglect the potential benefits of geographic dispersion. For example, if an organization can manage daily handoffs of work between remote sites and focus attention around the clock on critical-path tasks, it is possible to take advantage of widely dispersed time zones. 3 We could theoretically extend the productive hours of the day from the current 8- to 10-hour norm to somewhere near the limit of 24. This is perhaps a distant goal as a general model for development, but occasional benefits—for example, accelerated problem investigation or a distributed daily test-and-fix cycle—are possible.
Moreover, we probably think of "distributed" work in much too limited a way. Distances need not be global to be important. 4-5 In fact, being in another building or on a different floor of the same building, or even at the other end of a long corridor, severely reduces communication. Solutions that help globally distributed colleagues work together more effectively will often help those in the same zip code as well.
Physical separation among project members has diverse effects on many levels.
Once a particular set of project sites has been determined (a decision outside the scope of this issue), deciding how to divide up the work across sites is difficult. Solutions are constrained by the resources available at the sites, their levels of expertise in various technologies, the infrastructure, and so on. An ideal arrangement would let the sites operate as independently as possible while providing for easy, flexible, and effective communication across sites. A number of models are possible and appropriate under different circumstances and require different coordination mechanisms. 6
Another fundamental challenge is the organization's resistance to GSD. This resistance often surfaces because of misalignment between senior and middle management on the intent and perceived benefits of GSD. Many individuals might believe their jobs are threatened, experience a loss of control, and fear the possibility of relocation and the need for extensive travel.
GSD requires close cooperation of individuals with different cultural backgrounds. Cultures differ on many critical dimensions, such as the need for structure, attitudes toward hierarchy, sense of time, and communication styles. 7 While many people find such differences enriching, they can also lead to serious and chronic misunderstandings, especially among people who do not know each other well. An email, for example, from someone in a culture where communication tends to be direct might seem abrupt or even rude to someone from a different background. A different sense of time can lead to acrimony over the interpretation and seriousness of deadlines.
Cultural differences often exacerbate communication problems as well. When people are puzzled as to how to respond to odd-sounding messages, they often just ignore them or make uncharitable attributions about the sender's intentions or character.
Software development, particularly in the early stages, requires much communication. 8 In fact, software projects have two complementary communication needs. First, the more formal, official communications need a clear, well understood interface. For crucial tasks like updating project status, escalating project issues, and determining who has responsibility for particular work products, a fuzzy or poorly specified interface loses time and lets problems fall through the cracks.
Disruption to a second, vital communication channel can be surprisingly crippling 9: developers not located together have very little informal, spontaneous conversation across sites. Informal "corridor talk" helps people stay aware of what is going on around them, what other people are working on, what states various parts of the project are in, who has expertise in what area, and many other essential pieces of background information that enable developers to work together efficiently. One result is that the issues, big and small, that crop up on a nearly daily basis in any software project can go unrecognized or lie dormant and unresolved for extended periods. The absence of ongoing conversation can also lead to surprises from distant sites, potentially resulting in misalignment and rework. The more uncertain the project, the more important this communication channel is. 10
These issues are even more complex in outsourcing arrangements. The fear of loss of intellectual property or other proprietary information about products or schedules leads to restricted or filtered communication, often seriously impairing this critical channel.
Without effective information- and knowledge-sharing mechanisms, managers cannot exploit GSD's benefits. For example, they might fail to promptly and uniformly share information from customers and the market among the development teams. When project leaders disseminate status information inadequately, teams cannot determine what tasks are currently on the critical path. Needed expertise might be available but cannot be located and hence is not exploited. Also, owing to poor knowledge and information management, teams miss many reuse opportunities that otherwise would have saved cost and time.
Poor documentation can also cause ineffective collaborative development. The resistance to documentation among developers is well known and needs no emphasis. In GSD, however, in addition to documenting the various artifacts, updating and revising the documentation is equally important. To prevent assumptions and ambiguity and to support maintainability, documentation must be current and reflect what various teams are using and working on.
When teams hand off processes between sites, the lack of synchronization can be particularly critical—for example, if the development team at one site and the test group at another site define "unit-tested code" differently. Synchronization requires commonly defined milestones and clear entry and exit criteria. Though concurrent development process models have been suggested in the literature and used, 11-13 effectively implementing concurrent engineering principles in GSD often becomes difficult because of volatile requirements, unstable specifications, the unavailability of good tools that support collaboration across time and space, and the lack of informal communication. Some groups practice risk management in a traditional fashion, not taking into account the possible impacts of diverse cultures and attitudes.
Since networks spanning globally dispersed locations are often slow and unreliable, tasks such as configuration management that involve transmission of critical data and multisite production must be meticulously planned and executed. The need to control product changes and to ensure that all concerned hear about them is much greater in GSD. Other common issues include using incompatible data formats and different versions of the same tools.
Each article in this issue provides some answers to managers and engineers navigating these difficult waters. They describe new tactics and techniques as well as hard-won practical lessons from experience.
As we noted earlier, distance is a major issue in GSD leading to coordination, communication, and management problems. In "Tactical Approaches for Alleviating Distance in Global Software Development," Erran Carmel and Ritu Agarwal provide several approaches that can be applied across a range of geographically distributed projects. Audris Mockus and David M. Weiss, in "Globalization by Chunking: A Quantitative Approach," offer a method for using code change history to compute the degree of "relatedness" of the work items at two sites. They further propose a method for distributing work in a way that minimizes the need for coordination across sites.
In "Using Components for Rapid Distributed Software Development," Alexander Repenning, Andri Ioannidou, Michele Payton, Wenming Ye, and Jeremy Roschelle describe their experiences using a component architecture to support work distribution across sites. Based on their large, geographically distributed testbed for publishing educational software applications, the authors outline a rapid production process using components suited for distributed development. This enables each site to take ownership of particular components and work on them independently without much need for intersite communication and coordination.
In our experience, training programmers to think and behave like software engineers is an uphill task. Many educational programs now include team-oriented work, and with globalization so pervasive, they also need to train their students with geographically distributed development in mind. Jesús Favela and Feniosky Peña-Mora, in "Geographically Distributed Collaborative Software Development," describe a project-oriented software engineering course and show how students in two different countries collaborated using an Internet-based groupware environment. While their objective in designing the project was educational, their experiences are significant to the business community.
Software outsourcing is increasingly popular among corporations as an economically and strategically attractive business model. As companies outsource their software needs to software houses across national borders, the two independent organizations must interact—causing the dynamics of globally distributed software development to surface rather strongly. In a thought-provoking article, "Synching or Sinking: Global Software Outsourcing Relationships," Richard Heeks, S. Krishna, Brian Nicholson, and Sundeep Sahay report on three interesting case studies and capture their successful outsourcing strategies to maximize business value.
Finally, we offer three excellent articles summarizing real organizational experiences, lessons learned, and good practices. In "Surviving Global Software Development," Christof Ebert and Philip De Neve narrate Alcatel's experience in globally distributed software development and synthesize the good practices they observed in a large operation involving 5,000 engineers. Robert Battin, Ron Crocker, Joe Kreidler, and K. Subramanian, in "Leveraging Resources in Global Software Development," report on their experiences and approaches while working on Motorola's 3G Trial Systems project, which spans six countries. In "Outsourcing in India," Werner Kobitzsch, Dieter Rombach, and Raimund Feldmann capture their experiences and lessons learned with distributed software development at Tenovis, a German company. Interestingly, while these articles are from different companies operating in different cultural settings, there is a marked commonality in experiences gained and approaches that worked.
Given the global reach of today's large corporations and the global market for software products, few software engineers will remain unaffected as the globalization trend surges forward. As we increasingly work in virtual, distributed team environments, we will more and more face formidable problems of miscommunication, lack of coordination, infrastructure incompatibility, cultural misunderstanding, and conflicting expectations—not to mention the technical challenges of architecting products for distributed development. We hope the advances in collaborative tools and multimedia, Web technology, 14-15 and a refined understanding of concurrent-engineering principles will help us address these challenges.
We thank the reviewers who contributed their valuable time and expertise toward development of this special issue. Our sincere thanks also to Dawn Craig at IEEE Software for her meticulous efforts helping us put together the issue.