Research and Advances
Computing Applications Virtual extension

Global Software Development: Where Are the Benefits?

  1. Introduction
  2. Case Setting
  3. Assumed Benefit 1: Reduced Development Costs
  4. Assumed Benefit 2: Leveraging Time-Zone Effectiveness
  5. Assumed Benefit 3: Cross-Site Modularization of Development Work
  6. Assumed Benefit 4: Access to Large Skilled Labor Pool
  7. Assumed Benefit 5: Innovation and Shared Best Practice
  8. Assumed Benefit 6: Closer Proximity to Market and Customer
  9. Conclusions
  10. References
  11. Authors
  12. Footnotes
  13. Figures
  14. Tables
  15. Sidebar: Methodology

Global Software Development (gsd) is increasingly becoming the normal practice in the software industry, readily evidenced by U.S. estimates that the value of the offshore software development market has increased 25-fold over the past 10 years, to the extent that one-quarter of U.S. spending on application development, integration and management services is expected to go off-shore according to recent predictions. There are many potential benefits that can arise from GSD. The most frequently cited one is that of reduced development costs due to the salary savings possible.4,5 Also, GSD can lead to reduced development duration due to greater time zone effectiveness as companies practice the so-called ‘follow-the-sun’ software development model.3,4,5 GSD also affords new opportunities for cross-site modularization of development work,6,7 potential access to a larger and better-skilled developer pool,2 and the possibility of greater innovation, learning and transfer of best practices.5 Finally, GSD can facilitate closer proximity to markets and customers.7,9

However, GSD also introduces a number of challenges in relation to communication, coordination and control of the development process. These arise due to the distances involved in three dimensions – geographical, temporal, and socio-cultural (See Figure 1). As a consequence, much research and practice has focused on trying to find ways to overcome the GSD challenges identified in Figure 1. In the literature to date, the potential benefits of GSD are usually just mentioned very briefly, if they are mentioned at all, and the realization of these benefits seems to be more or less taken for granted. The primary focus instead is on how the problems inherent in GSD might be addressed. Here, we reverse this trend and focus instead on the benefits and the extent to which they are actually being realized in practice in three global companies practicing GSD.

Back to Top

Case Setting

Our research focused on three global software development companies, which we will refer to as International Semiconductor, Global Investments Inc., and Digital Solutions. Each company is headquartered in the US, and all are directly involved in intensive GSD. At its Irish site, International Semiconductor employs 125 people as part of the Infrastructure Processor Division, with GSD teams based at several international sites, including the U.S., Malaysia, China, India, and Poland. Global Investments Inc. provides financial services and investment resources internationally and is one of the largest private companies in the U.S. The company has been developing software in Ireland since 2001, and currently employs around 200 people there. The software products developed are supplied to internal customers in the U.S., by coordinating with several software development teams in the U.S. and others in India. Digital Solutions provides desktop support services right through to mission critical service delivery. The Irish team of around 130 people develops remote support and proactive services.

Back to Top

Assumed Benefit 1: Reduced Development Costs

One of the most obvious reasons for organizations to embark on a challenging and risky endeavour such as GSD is, not surprisingly, the potential to reduce development costs.4,5,6 By moving parts of the development work to low-wage countries, the same work can be done for a fraction of the cost.

In our research, all three companies stated that reducing costs was one of the main drivers for GSD from the outset. In Global Investments, the Indian internal customer billed half of what the Irish team charged for essentially the same work. A base annual salary of U.S.$15,000 for a software developer in India, is one quarter of the salary of an Irish developer, who in turn earns half that of a developer in the US. While this eight-fold salary saving seems like a significant up-front benefit, this doesn’t tell the whole story. Indeed, the inability of the Indian customer to achieve four-fold savings relative to the Irish team suggests that GSD introduces complexities that corrode the initial cost savings.

Our case study companies found that coordination complexity increased when developers are distributed. This is supported by the findings of Herbsleb et al.9 that modification requests (MRs) involving multiple sites took 2.5 longer to resolve and tended to involve more people, compared to single-site MRs. In practice, GSD in our case study companies necessitated an increased number of managerial roles. In the virtual team environment, there was a tendency to replicate management roles at the local and remote site. A Digital Solutions manager suggested that the culture of the India operation tended towards a very top-heavy management structure. Furthermore, Global Investments Inc. found that developers in remote sites took quite a long time – about three months – to achieve the competency level to contribute meaningfully to development.

While such ramp-up problems are a well-known feature of software development projects, they are exacerbated in GSD due to the increased coordination and control complexity. To help reduce this, Global Investments Inc. assigned a developer located in a high-cost location as a remote “buddy” for each new offshore developer to help introduce them to the work involved, using up time that would otherwise be available to the higher cost developers to develop software. Also, a negative knock-on effect of transferring development to lower cost regions was the fear it created among the local developers that their jobs were under threat, which in turn created an atmosphere in which it was difficult to establish trust. This was further exacerbated by the drive to save costs, which meant that travel between sites was rarely sanctioned, certainly not for those doing the actual hands-on development. With no face-to-face communication, it was very difficult to create a feeling of ‘teamness’ and to establish trust.4

Interestingly, while it was generally accepted that it was essential that developers should travel to meet each other to establish trust and a sense of teamness, in all cases travel restrictions at the developer level curtailed severely any such initiatives. Therefore, the companies were saving money when employing cheaper developers offshore, but at the same time, these developers did not get the chance to meet each other, thus constraining the possibility of building effective long-term relationships with remote colleagues.

While it has been argued that formal models may not be any more accurate than expert estimation,10 the lack of models for calculating the true cost of distributing development was a recurrent theme in each company. Several interviewees identified the need for a comprehensive model for calculating the true total cost of development in a GSD context.

Back to Top

Assumed Benefit 2: Leveraging Time-Zone Effectiveness

Having developers located in different time-zones can allow organizations to increase the number of daily working hours in a ‘follow-the-sun’ development model which can decrease cycle time.3,8,9

Even though the companies in our research certainly acknowledged the possible benefits of time-zone effectiveness, achieving this benefit was proving problematic for most GSD tasks. International Semiconductor found that it was possible to accomplish the testing phase using hand-offs, and Global Investments Inc. found they could achieve this for defect resolution and support tasks. However, the companies generally accepted that there were significant problems due to temporal dislocation, and strategies were instigated to combat these. International Semiconductor instigated a policy of never distributing development across more than two time-zones, thereby mitigating the effects of time zone separation. Interestingly, the companies seemed in effect to strive for a model diametrically opposed to ‘follow-the-sun’ development – that is, rather than seeking to extend the virtual working day, they tended to shift their working hours in order to maximize the number of overlapping work-hours across sites. Indeed, the companies viewed time-zone differences not as a potential benefit but as a negative side effect of GSD. A manager in Digital Solutions commented about their flexible work practices:

“People go out of their way to work late at night. I have regularly had calls with US workers at 6am, and I also work quite late. The official workday [in Ireland] is 8.30 A.M. to 5.15 P.M., but that’s not applied at all. Taking calls at home can become quite intrusive on one’s family and personal life. In the long run, you get burnout of people.”

Thus, despite being a widely assumed benefit of GSD, harnessing time-zone effectiveness is not widely realized. Delayed response times and the fact that all development phases are not suitable for ‘follow-the-sun’ development make this hard to achieve. Instead, we found a tendency to shift work hours to increase the number of overlapping hours across sites.

Back to Top

Assumed Benefit 3: Cross-Site Modularization of Development Work

The nature of GSD allows development work to be sub-divided into modules, which may be developed in parallel across multiple sites,5,6,7 thus leading to reduced cycle time. We found varying approaches with regard to the modularization of work (See Figure 2). The Digital Solutions team practiced the ‘virtual team’ model, treating all team members as members of one large team, albeit physically separated by large distance. International Semiconductor adopted a different approach, that of loosely-coupled teams in which they chose to explicitly modularize tasks by feature. They treated one set of co-located colleagues as one team, with all teams coordinating to achieve the completion of the end product. One manager in International Semiconductor explained,

“We try to have as few dependencies as possible on other teams’ work. In general, we try to have feature dependency orthogonal across sites.”

International Semiconductor recognized that co-location of team members is needed to develop certain units of functionality. They chose to limit the extent of cross-site modularization by restricting the distribution of development tasks to a maximum of two global locations.

Global Investments Inc. also tended towards the loosely-coupled teams approach. Discrete ‘chunks’ of work were sent to the remote site, providing that site with some level of ownership within the project, thus improving the sense of goodwill. A Global Investments Inc. manager commented on the importance of site independence,

“You try to package pieces of work that they can run with, rather than having something that’s going to shuttle back and forth a lot. From their perspective, it’s easier for them [Indian developers]. They’ve got some latitude to get on with it, a bit more independence, and that’s a big thing.”

However, the level of granularity of modularization is important. At Global Investments, they experienced a loss of efficiency as some tasks proved too small to meaningfully distribute in practice.

Also International Semiconductor found that a general sense of cross-site teamness amongst developers did not seem to emerge:

“Because of the division of work according to features, we remain two different teams.”

Furthermore, modularization of work can create integration problems. For example, if remote teams become too independent, with a lack of intersite communication during the development stage, there may be difficulty in integrating their work in the end when incorrect or conflicting assumptions about functional requirements come to light. The emphasis by International Semiconductor on division of labor seems to have led them away from the established practice of continuous integration. Perhaps surprising in the current era of agile development,1 no participant in our study commented on using agile practices, such as test-driven development, which have proven to help avoiding “big bang” integration in GSD.

In summary while the nature of GSD encourages development work to be sub-divided into individual modules, and can afford some advantages in parallel cross-site development, companies need to be wary of reduced communication between sites, leading to problems at the integration stage. In earlier research we have seen the importance of a separation of concerns when decomposing into modules in general, and it appears that these principles could be extremely relevant again in the specific case of GSD.11

Back to Top

Assumed Benefit 4: Access to Large Skilled Labor Pool

It is widely known that talented developers have the greatest impact on development productivity and quality. However the shortage of sufficient developer talent is a major constraint that organizations face in their domestic location. Countries such as India and China, with populations in excess of 1 billion people, are producing hundreds of thousands of software engineers. Thus, GSD has the potential to facilitate access to a large pool of highly skilled workers.4,5,9

All three companies highlighted the fact that GSD allowed them to access a larger labor pool with specialized skills. A manager in International Semiconductor added that the scalability available to them as a result of access to a large labor pool allows them to increase greatly the size of their development efforts without dramatic changes to the organization. The site manager in International Semiconductor was particularly pleased with the skill levels of graduates in India and Malaysia. In India, International Semiconductor can recruit relatively low-waged graduates from the top universities in India, choosing Ph.D. graduates, resulting in access to what was described as “genius employees.” However, a major disadvantage was the high attrition levels that arose from the rapid growth in the employment market for software developers in these countries.

Other disadvantages linked to seeking out workers overseas are due to the consequent increase in cultural distances between team members. All three companies noted serious communication problems due to cultural differences within their GSD teams. An architect at Digital Solutions offered an example of problems due to different cultural backgrounds:

“I was trying to get people to use the same tools. I said, ‘This is like a religious war.’ One of the guys in the US said, ‘Well, I’m highly religious, I go to church, I really care about it, so what do you mean?’ They took me up completely wrong.”

International Semiconductor reduced cultural distance at times by outsourcing to so-called domestic third-party providers; that is, companies whose customer liaison representatives resided in the U.S. while actual outsourced work tasks were completed in lower-cost locations such as India. This meant that they could communicate with the U.S.-based offices of the third party companies.

Back to Top

Assumed Benefit 5: Innovation and Shared Best Practice

It has been suggested that due the diverse backgrounds of GSD actors can lead to increased innovation and shared best practice amongst team members.5 A manager in Global Investments confirmed by suggesting,

“Having people coming from different backgrounds will always help, getting different views from different people, since people coming from different parts of the world would have different ways of doing something.”

A software engineer at International Semiconductor also acknowledged the effect of working with people from different cultural backgrounds:

“When working a lot with people in another country, I even found my thought process changing!”

However, in reality, GSD developers had little opportunity to share best practices with each other. Lack of face-to-face contact inhibited informal communication, and reduced sharing of ideas between different sites. Complex processes, such as those inherent in best practice innovation, could not be transferred with a narrow communication medium such as email. Furthermore, it was recognized that the abilities of developers in lower-waged locations tended to be underestimated. With a lack of respect for others’ abilities, it is less likely for them to learn best practices from others. Finally, in the context of suspicion and fear of job losses, there was little incentive for sharing of innovation and best practices.

Back to Top

Assumed Benefit 6: Closer Proximity to Market and Customer

By establishing subsidiaries in countries and on continents where one’s customers are located, a more direct interaction becomes possible.7,9 However, only one of the companies in our study noted the benefit of locating development efforts closer to their target market. As International Semiconductor is mainly a manufacturing company, many of their technology customers are located in China. Having local employees located in China, they are close culturally and linguistically to the customer, and have better knowledge of local business conditions. However, having developers located in the customers’ market implies that there will be a great cultural divide amongst team members – which would introduce the socio-cultural problems discussed above. Therefore, companies locating some of their development efforts in local markets in order to be closer to their customers must also develop strategies for overcoming such problems.

Back to Top


Table 1 summarizes the main insights gained from this study in terms of how the assumed benefits of GSD played out in the studied organizations.

While there are many significant beneficial aspects of GSD, our study clearly shows that these benefits are neither clear-cut nor can their realization be taken-for-granted as the GSD literature may lead one to believe. Specifically, anyone engaging in GSD should be aware of the many risks associated with these “benefits”. Do not assume that overall costs will be reduced, as lower wages are countered by the overhead of higher managerial complexities. Pure follow-the-sun software development seems unrealistic, and companies may prefer to modularize work instead of taking advantage of developers situated in various time-zones. Seeking out employees in rapid growth markets can backfire, with very high attrition rates reported. Sharing of best practice between cultures can be problematic, especially if those expected to share feel they are giving away their competitive edge to lower-waged colleagues, or do not trust their abilities. Taking advantage of closer proximity to foreign markets leads to a number of socio-cultural problems which have to be addressed.

Back to Top

Back to Top

Back to Top

Back to Top


F1 Figure 1. Opportunities and challenges in GSD, adapted from

F2 Figure 2. Different approaches to team structure in GSD: Virtual teams vs. loosely-coupled teams.

Back to Top


T1 Table 1. Extent of realization of GSD benefits.

Back to Top

    1. Ågerfalk, J. P. and Fitzgerald, B. Flexible and distributed software processes: Old petunias in new bowls? Comm. of the ACM 49, 10, (2006) 26–34

    2. Bass, M. and Paulish, D. Global software development process research at Siemens, In Proceedings of the 3rd International Workshop on Global Software Development, 11–14, <>

    3. Carmel, E. Global Software Teams: Collaborating Across Borders and Time Zones, Prentice Hall, Upper Saddle River, NJ, 1999.

    4. Carmel, E. and Agarwal, R. Tactical approaches for alleviating distance in global software development. IEEE Software 18, 2, (2001) 22–29.

    5. Damian, D., Lanubile, F. and Oppenheimer, H.L. Addressing the challenges of software industry globalization: The workshop on global software development. In Proceedings of the 25th International Conference on Software Engineering. IEEE Computer Society (2003), Los Alamitos, 793–794.

    6. Ebert, C. and De Neve, P. Surviving global software development. IEEE Software 18, 2, (2001) 62–69.

    7. Grinter, R.E., Herbsleb, J.D. and Perry, D.E. The geography of coordination: Dealing with distance in R&D work. In Proceedings of the. ACM SIGGROUP International Conference on Supporting Group Work, ACM Press, (1999) New York, 306–315.

    8. Herbsleb, J. D. and Grinter, R.E. Splitting the organization and integrating the code: Conway's law revisited, In Proceedings of the 21st International Conference on Software Engineering, (1999) ACM Press, NY, 85–95.

    9. Herbsleb, J. D., Mockus, A., Finholt, T. A. and Grinter, R. E. Distance, dependencies, and delay in a global collaboration, ACM 2000 Conference on Computer Supported Cooperative Work, ACM Press, NY, 319–328.

    10. Molokken, K., and Jorgensen, M. A review of surveys on software effort estimation. In Proceedings of the 2003 International Symposium on Empirical Software Engineering.

    11. Parnas, D. On the criteria to be used in decomposing systems into modules. Comm. of the ACM 15, 12, (1972), 1053–1058.

    12. Sahay, S. Global software alliances: The challenge of standardization. Scandinavian Journal of Information Systems 15, (2003) 3–21.


Join the Discussion (0)

Become a Member or Sign In to Post a Comment

The Latest from CACM

Shape the Future of Computing

ACM encourages its members to take a direct hand in shaping the future of the association. There are more ways than ever to get involved.

Get Involved

Communications of the ACM (CACM) is now a fully Open Access publication.

By opening CACM to the world, we hope to increase engagement among the broader computer science community and encourage non-members to discover the rich resources ACM has to offer.

Learn More