Challenges and Solutions in Distributed Software Development

Andr Meyer e andre.meyer@uzh.ch s09-736-398

Department of Informatics University of Zurich Zurich, Switzerland

Abstract. The growing globalization attracts many enterprises to distribute their software development. Aside multiple risks and problems, there are a variety of advantages; e.g. saving time and money, nding the right people and working at the customers place. In this paper, the motivation for the development of software in a scattered environment is summarized. Furthermore, challenges such as cultural and communication problems, time-zone dierences, management issues, language barriers, etc. are addressed together with selected solutions to avoid the collapse or delay of projects.

Keywords: distributed software development, challenges, motivation, reasons, problems, solutions, communication, individual aspects, management, technology

Introduction

Distributed software development (DSD) is gaining an increasing popularity. The studies referenced in this paper were published between 1996 and 2010, showing the relevance this topic has. According to Herbsleb et al. [2], enterprises have made large investments over the last decade, which enabled the move from local to global markets. This resulted in the invention of new competition and collaboration forms. Prikladnicki et al. [5] made an interesting approach to separate software development into four parts: Onshore insourcing is the development of software within the same company in the same country. Onshore outsourcing denes software development within the same country but in another development company. Internal oshoring means worldwide development of software within the same company.

Oshore outsourcing is dened as the globally distributed development of software in a foreign country outside the own company. Most of the challenges and solutions described in this report are likely to be the same in all cases. Therefore, the following denition suits the intents of this paper better: Holmstrom et al. [13] dene DSD as the distribution across geographical, organizational, temporal and stakeholder boundaries. Overseas development cause more diculties than traditional (collocated) development [14] because new parameters and circumstances are added to the already complex problem of software project management [4]. In this report, I try to answer the following two questions: Question 1. Why do companies want to develop their software in a distributed way? Question 2. What are the big challenges and possible approaches to solve them? In order to answer these questions, this paper rst shows possible reasons and the motivation for DSD (chapter 2), examining economical, global and personal aspects. The paper then discusses diculties, possible problems and risks as well as multiple approaches and hints to avoid unsatised customers, employees and managers due to delayed projects and their usual negative consequences (chapter 3). Chapter 4 compares the main challenges and their solutions and provides a critical view on the presented works. Finally, the paper concludes in chapter 5.

Motivation for Distributed Software Development

This chapter gives a short overview of possible reasons why companies develop parts or whole packages of a certain software in a distributed manner. In the companies perspective, these reasons are mostly advantageous. On the one hand, there is a certain risk reduction by having the knowledge distributed across several sites [7]. On the other hand, the risk management must keep in mind that delays, wrong order of transactions, bad quality, bad agreements, etc. may negatively aect the success of a project. These problems may be more severe in a distributed environment than in local conditions and will be discussed in chapter 3. 2.1 Cost

Probably, the most important reason to develop software distributed is the difference in development costs, i.e. the economical savings [10]. Lots of companies develop software in low-cost countries such as India or China to reduce their labour costs [7]. According to Prikladnicki et al., oshore IT services could potentially save about 35-65% on their in-house costs. It is estimated that in India alone, the market size will grow from $10.3 billion in 2001 to $77 billion in 2008 [5]. This clearly states the importance of the globalization and that this eect will likely increase in the future.

2.2

Availability of people

The availability of people in dierent places around the world is useful for two reasons: First, there is a better availability of talented people worldwide than in a local environment [7]. There are probably not enough experienced people in the current workplace or they may be too expensive for the company to pay. For example, moving near a university will give access to talented students. Furthermore, important consultants that remotely join a team for a limited period of time [3] could stay at their place without the need to travel. Lamersdorf et al. [7] summarise this aspect: Sometimes, talented people were scattered across different places and making them working together in a distributed way was easier than moving them all to one place. Second, some projects suer under severe pressure to improve time-to-market. They could benet of the time zone dierences by developing round-the-clock [10]. This allows to work on time critical tasks near the limit of 24 hours. This could immensely accelerate problem investigation or distributed daily test-andx cycles [2]. This is further discussed in chapter 3.1. 2.3 Local conditions

Another big advantage is the quick formation of virtual corporations and virtual teams to exploit market opportunities [2]. Sometimes, there is the necessity of getting closer to customers in order to use specic expertise to customize or localize the products [2,10] or because the customer requires it [7]. Moreover, national policies or government restrictions could also require suppliers to locate research and development in the customers country [10]. The reason is that there may be restrictions which permit the development of certain software outside the own country [1].

Challenges and Solutions

The decision of developing software distributed may cause high risks, problems and other challenges. They are classied in four sections, each discussing the challenges together with recommendations to avoid them. 3.1 Communication

Introduction. Herbsleb et al. describe that communication and coordination plays a major role in the projects delay. In addition, development tasks on multiple sites take much longer than comparable collocated tasks. Miscommunication results in discussions that would not have come up with correct coordination, causing employees to be dissatised and angry [2]. The problems in distributed communication are versatile: delayed feedback, restricted communication, less shared project awareness, etc. [1]. Poor knowledge management and documentation causes more work (which negatively aects cost and time) because teams

miss the opportunities to reuse some code [2]. Miscommunication is a topic, which has to be taken serious because it can dramatically aect the success of a project. The denition of communication protocols [5], some basic rules of communication and the reduction of intensive collaboration in distributed teams [1] is necessary. In addition, it is important to deploy knowledge transfer mechanisms [4] and dene standards for documentation: Decisions and documenting specication renements must be recorded and deployed to all involved teams to prevent misunderstandings and troubles [8].

Diculty of initiating contact. Working in dierent time-zones becomes a problem when it gets to synchronous communication. Although, for example, the time dierence between UK and Germany is only one hour, the possibility to synchronously communicate is restricted to only a few hours. The reason is that employees from UK start their work later but work longer and the contrary usually happens in Germany [8]. Herbsleb et al. point out that even if the distribution of the development is close, e.g. in another building or on a dierent oor of the same building, or even at the other end of a long corridor, communication is severely reduced. Therefore, a developer may get blocked multiple days due to some information needs [1,8]. If he just could step into a neighbouring oce of a team mate to ask for help, he would probably have needed only a few minutes to solve his problem. This lack of ad-hoc communication between software developers can cause not only an increase in coordination problems but also a decrease in collaboration between remote sites [8]. Spontaneous, informal conversations, such as a short talk in the mensa or in the coee break, could improve the team spirit and also let the developers nd little issues, which probably would not be recognized otherwise, potentially resulting in rework, higher failure rates and higher costs [2,8]. Moreover, people could stay aware of what others are doing right now or of the status of a part of the project in an easy way. In a distributed setting, these information are missing or have to be shared in another way, which is further discussed in this chapter and chapter 3.4. Overall, people communicate less in distributed teams because it is troublesome and exhausting - they use it only when there is no other way [8]. By limiting the level of distribution to the same time-zone, this problem could be solved easily. If this is no possibility, companies have to nd a way to handle communication over large distances. It may be an advantage to use asynchronous communication (e.g. e-mail) rather than synchronous communication (e.g. telephone, chat) [1]. Asynchronous communication has the disadvantage that it could easily produce large overhead, i.e. information that the developer does not need. But it usually is better to have too much information and the need to lter it than to have too little [1]. When synchronous communication is needed (instant feedback), instant messaging or group chats should be preferred from telephones [1]. The reason is that non-native speakers usually have problems to express themselves because they do not have enough time to lis-

ten, think and translate everything. They need enough time to reect before answering a question [13]. Moreover, there is also the need of presence awareness tools and shared calendars [1] to be able to arrange these synchronous meetings and to know what others are doing right now. In addition, team members have to be exible to achieve overlap with remote colleagues [13]. Depending on the time-zone dierence, they probably should start work earlier in the morning or work longer in the evenings in order to nd an appointment to communicate synchronized. This idea is applied by companies like Intel, which try to let their teams act exible and adjust hours to get overlaps, what only needs a few organizational changes as long as the time dierence is small. If this problem is not solved properly, people may feel behind and abandoned, what makes them frustrated in long-term projects and could burn out people [13]. Working in dierent time-zones has one big advantage: Enterprises could organize the development according to the follow-the-sun-model [7]. A developer commits his changes in the evening, others test it during the night (their own work-day) and the next day, he has results and more information to work on. According to the studies in dierent worldwide operating enterprises (Intel, HP, etc.), Holmstrom et al. found that this approach is not considered practical in some cases because it causes huge planning costs and increases the communication problems discussed above.

Find the responsible person on the other side. The lack of ad-hoc talks and knowing each other leads to the problem that people do not know what others are doing. In case of problems or questions, they do not know whom to contact [7] and it is dicult to identify roles and responsibilities [4]. First of all, awareness of the entire team and more detailed knowledge of people that developers plan to work with is really important [6]. Group awareness information includes knowledge about who is on the project, where in the code they are working, what they are doing and what their plans are [6]. In addition, they must be aware of who the experts are in given topics [1] to know whom to contact in case of a problem. This is why face-to-face meetings should take place at an early project stage (e.g. the kick-o meeting) [11]. It usually also makes sense to exchange specialists between the distributed places, which are well suited for a long-time communication-channel between two distributed places [8]. In order to reduce coordination and awareness requirements, tasks should be split into components and allocated to a software engineer who is responsible for one of these sub-tasks [6]. These components should let the team work as independently as possible without much need for inter-site communication and coordination [2]. Raymond quotes in [12] that complexity and communication costs of a project rise with the square of the number of developers. He then suggests to avoid this explosion of connections by having only a small set of core developers, with a larger halo of people whose activity is limited. Specic questions should be answered on-demand, e.g. through repository logs,

issue and bug trackers, project documentation or by asking other developers [6]. In open source DSD, Gutwin et al. [6] use developer mailing lists to distribute dynamic information sources. The developers lter these lists for their need. It remains uncertain if this approach could possibly also be applied to a normal distributed setting and therefore needs further research. Ability to communicate eectively. Another problem in DSD is the inability to share the same environment [8]. Sometimes a developer wants to point out something on his screen or on the whiteboard, or there is the need to review documents together. It is also dicult to pass other general information across sites to point out how things work, what issues have priority, to communicate urgency [10] or to solve problems. As mentioned earlier in [4], there may also be language barriers, which lead to miscommunication. According to Holmstrom et al., this is the primary reason for conicts and misunderstandings. All these reasons and technical problems, which are discussed later, lead to a very dicult setting to communicate eectively. For dierent situations, there is the need of multiple communication modes, including face-to-face synchronous communication as well as ways for asynchronous communication [4]. It is important to provide training in collaboration and coordination of these tools (see chapter 3.4 for details). The user should be able to choose what ts his needs best. Another aspect is that everyone has to be aware of possible language problems. It is usually better to dene one language in which all communication, documentation and discussions happen [5] and let non-native speakers choose the communication channel. Using only one language is important for the documentation because it guarantees uniformity, a better quality and the possibility that everyone is able to read it. Another approach could be to focus on asynchronous communication or to dene a buddy system to team up two developers from dierent places, which are responsible for each other [13]. 3.2 Individual

Some groups practice risk management in a traditional fashion, not taking into account the possible impacts of diverse cultures and attitudes [2]. Each individual has a dierent thinking and experience, there may be non-team-workers and other cultural barriers, which are addressed in this chapter. Individual related reasons obviously also aect the way of communication discussed above. Cultures. According to the ndings of Herbsleb et al., German people are more direct than English. Communication between developers of these two countries may lead to problems because the English developer may on the one hand think the German is rude and on the other hand, the German may think the English developer should come to the point. In some countries, developers would

always say yes to certain requests regardless of any circumstances, even to requests which are impossible to nish within a given time-frame. The problem is that they avoid saying no due to their cultural pride (cited in [13]). This could result in big design and planning errors. In contrast to Indian professionals which usually reply immediately, Japanese professionals take longer time to reply due to their communication culture which values completeness in their mode of replying [13]. This three examples clearly show organizational and national cultural barriers as well as political and religious dierences. This topic is also deeply discussed in many other papers [1,4,7,8,10]. Each developer has distinct backgrounds [10] and dierent experience with dierent processes and trainings, conicting expectations, a dierent sense of time and communication styles [2]. This could obviously lead to misinterpretation due to the lack of cultural context [1]. To avoid cultural problems, people with complementary skills and cultures should be grouped together [15]. Every signal of a possible problem should be addressed and solved directly to inhibit conicts which negatively aect the project. Mixed teams could be trained on dierent cultures to instil a sense of cultural awareness [4]. Furthermore, it could be an advantage to assign work to regions close to the customer in order to reduce these mentioned cultural dierences between developing site and customer site (cited in [7]). Resistance. When developers are confronted with the distribution of a project, they might build up a certain resistance because they believe that their jobs are threatened. They fear a loss of control, the possibility of relocation, to be more easily replaceable and the need for extensive travel [2]. It is obvious that the advancing globalization is aecting jobs previously considered untouchable [16]. This is the reason why there is a lack of willingness to communicate openly across sites [10] and why a lot of developers do not want to share their knowhow and their experience. It is important to clearly dene responsibilities, tasks and let no possibility of developing rivalry or lack of trust between groups [7]. Again, every sign of conict should be addressed and solved accordingly. The tasks must be systematically allocated or it is probably even better to let the developers decide which tasks they want to do. This works great in open source DSD and causes the highest motivation [6]. Furthermore, it may also be benecial to handle out long-term employment contracts to ensure the developer to be needed. Trust. As mentioned earlier, there may be the problem that two sides do not see themselves as team members or partners cooperating toward the same end. This is mostly caused by the absence of informal meetings (face-to-face communication) [8]. Knowing the other end or at least seeing the partners facial expressions, gestures or utterances may improve the evolvement of a team spirit [4].

Distance can reduce team cohesion in order to let the members feel to be a part of the team [1]. Problems seemed to be less signicant when the distributed development was done on a small scale, assigning work to individuals instead of groups [7]. It is necessary to create a team spirit, to let each team member know that everyone sits in the same boat and they can only survive by working together. Hence, it is necessary to increase trust from the beginning of a project [5] by arranging travels and meetings. Herbsleb et al. propose to use the travel budget and to bring the people together in the beginning of the project or as early as possible. The reason is that every mean to communicate will work better if developers, testers and managers had met each other face-to-face. According to Holmstrom et al., today, the project management seemed to have met themselves more often face-to-face than the developers did [13]. There is also the possibility of dening gregarious people to a gateway between distributed teams and let them travel frequently to the other side to help with cross-site issues [8]. This could be a good way if it is not possible to move the whole team to the distributed place due to cost limits or other reasons. Experience. Developers, even if working in the same place may have dierent quality standards what leads to misunderstandings. This could cause a lot of extra work. Lamersdorf et al. describe that in the beginning of a project it usually is dicult to estimate each others abilities and that there is the risk of getting delayed due to inexperienced work forces. There are only a few ways to nd out and judge the abilities and experience of other team members. They could get tested by developers with long-time development experience to prove their skills. In addition, it is important to compare the employees previous projects and jobs in order to check if he ts into the team. Specic training improves the developers skills, prevents the developer to be dissatised and could further reduce quality problems [2]. 3.3 Management

Blackburn et al. [9] state that developing software in a distributed manner makes the project managers job more dicult. On the one hand, they have to assign, coordinate, track and control tasks and developers. On the other hand, they must coordinate the information ows to support dierent levels of concurrent activities [1]. The expectations in collocated environments are high, but the requirements and responsibilities are even higher with the project to be distributed worldwide because of the reasons mentioned above. The processes, policies and standards are dierent from collocated development and it is hard to keep the overview of what happens where and when [4]. The lack of synchronization is another problem, which is addressed by Herbsleb et al. because the management might fail to promptly and uniformly share information from customers and the market among the development teams [2].

Another big challenge is the change management [5]: if the communication between both sides is not working absolutely consistent, the change management might fail, what clearly results in missing the target which moved meanwhile. A change in common milestones in one site may also aect other sites, which is often either not communicated or communicated too late [10]. For example, other problems occur in terms of project planning, schedule management, people management, conict resolution, risk management and quality management [4] all with heavy eects on the success of a project. As described earlier, it is dicult to decide how to divide the work across the side. An ideal arrangement would let the sites operate as independent as possible [2]. Although splitting the project into several little parts is important, it should only take place if the products are well-understood and their architectures, plans and processes likely remain the same [8]. Therefore, one should attend Conways Law: Have a good, modular design and use it as the basis for assigning work to dierent sites. The more cleanly separated the modules, the more likely the organization can successfully develop them at dierent sites [8]. The project gains could be remarkable: they possibly could result in long-term productivity through code reuse [9]. But it could also only yield to short-term gains through partial overlapping. It usually makes sense to clearly dene roles and peoples responsibilities for every projects module [4]. Another approach is to give away only easy tasks and develop the dicult tasks or tasks with the need of high quality in-house [7]. Bird et al. found very little dierence between distributed and collocated components when it comes to their characteristics such as code churn, complexity, dependency information, and test code coverage. According to Lamersdorf et al., in projects with a low maturity, in-house development should be preferred from distributed development because of easier and better quality and management control. The scarce time could better be used without additional communication and coordination delays and costs. In order to synchronize the work better, commonly dened milestones are required together with clear entry and exit criteria [2]. The described problem points out that there may be a general lack of standardization. It is important that common coding standards, standardizations of status reports, formalizations on change requests and system maintenance processes are well dened [5]. To summarise, it is important that managers try to understand the factors that enable multinationals and virtual corporations to operate successfully across geographic and cultural boundaries [2]. 3.4 Technical

Another problem of the lack of standardization is the infrastructure incompatibility, incompatible data formats, dierent versions of tools, etc. [2]. According to Prikladnicki et al., there is a lack of tools specially made for DSD. This statement is supported by the studies of da Silva et al. [4], which evaluated some

10

tools that support the project management of DSD. They found a big variety of traditional tools (such as e-mail, video-conference, wiki, etc.) but only a few specic tools (CAMEL, TAMRI, NEXTMOVE, etc.). On the contrary, Al-Ani et al. claim that there is no need for special tools because communication models tend to be hybrids of existing communication models, suggesting a continual evolution of team communications over time [11]. The diversity in operating environments [1] cause the inability to share the same environment and to see what is at the other site [8]. This is the reason why it makes sense to use the same tools in all distributed places. Moreover, problems like the earlier mentioned less shared project awareness, sharing of the same environment and nding the responsible person could be solved with traditional software tools like Microsoft Lync [17] in combination of Team Foundation Server [18]. They have features for collaborative software projects such as version control, reports, user-management and task-management. In addition, Microsoft Lync supports instant messaging, video-conferences, telephone calls, the possibility to share the screen or a whiteboard and users see the availability of other team members. The whole conguration managements needs to be meticulously planned and executed because of the slow and often unreliable networks and the importance of a working infrastructure [2]. The IT infrastructure must be secure and well dened in order to ensure infrastructure compatibility among geographic locations [4]. Da Silva et al. propose the use of traditional tools that are not specically designed for DSD because the users are familiarized with existing tools and need no practice in new ones [4]. In their systematic literature review, they found out that only 16 % of the analysed studies propose tools that specically are designed for DSD. People rather communicate via e-mail, video-conferences, chats, phones, teleconferences and wikis. These synchronous and asynchronous tools have the advantage that users can start the project right away without the need of being instructed. In contrast to da Silva et al., Venolia et al. [3] were certain that the use of current video-conference technologies could be increased. They developed a special solution, the so called embodied social proxy (ESP). According to their ndings, it signicantly improved in-meeting dynamics, the hubs (local team) awareness of the satellite (distributed team-member, usually experts), social presence and also the social connection between satellite and hub. They were able to reduce the communication uncertainty and increased engagement that lead to a stronger sense of proximity. Due to the fact that in their study only one member of the team was distributed, it is unclear of how ESPs can be applied in larger teams. In both cases, the obvious advantage of video-conferencing is the fast feedback. There is usually no need to wait for answers and one can also see the communication partners reactions (e.g. facial expressions). This requires, as stated before, a reliable infrastructure and the meeting members ability to use it [2]. These examples show that in terms of the use of the right tools, it depends on many variables and has no explicit solution. Communication techniques like

11

video-conferencing, electronic bulletin boards and work ow applications might add positive eects in some circumstances [8], but they do not directly address the core problems that are described in this paper.

Discussion

This chapter provides a summary of the main challenges and some selected solutions (see Table 1). The challenges are grouped according to the four main challenges in chapter 3 (communication, individual, management and technical). In order to keep a good lucidity, the table is truncated to one page. The second part of this chapter provides a critical view on these proposed approaches and tries to identify weaknesses. Bird et al. found out that there is very little dierence between distributed and collocated components and they made an unexpected but reasonable nding: the quality of the product is not negatively impacted by distributed (in-house) development. On the other hand, there were several studies with the opposite result [5,7,9]. It would be interesting, to nd the reasons for this miscellaneous results. One problem is likely to be the dierent set up of the studies: some were small scale (e.g. with students) in contrast to large-scale studies adhering thousands of developers scattered across multiple continents. This makes it difcult to compare. Moreover, the results from case studies are not necessarily applicable to other projects, because there usually are other circumstances and requirements. Only the study from Gutwin et al. analyses open source projects. It still remains uncertain how the ndings of this study could be applied to business cases. Open source projects dier from business scenarios in some aspects. For example, open source developers work voluntarily, have no right of compensation and work on the deliverable of their choice. In addition, open source projects usually have less restrictions and fewer requirements because they are dened by a lead or in the team and not by the customer or a supervisor. In terms of communication, this paper has two distinct propositions. On the one hand, one could improve the communication by dening rules, nding the right media for each situation or providing multiple communication models. On the other hand, the necessity of communication could be reduced by deploying knowledge transfer mechanisms or conveying proper documentation. This examples show that there is no suitable recipe for all situations. Moreover, there is the need of a study of how to communicate best in the beginning of the development phase. One of the highest risks in DSD projects is the human individual. For example, it is dicult to measure experience, cultural backgrounds and the ability to work in a team. The behaviour of each person may have huge impact in the overall motivation and the quality of the result. It is important that every signal of possible problems is addressed and solved immediately to inhibit conicts which have a negative eect on the project. Some of the presented studies describe tools which solve some of the problems of communication and collaboration. They usually do not describe problems

12 challenges comm. eective comm. solutions denition of comm. protocols + basic rules reduction of collaboration betw. distr. sites delayed feedback work in same time-zone use synchronous comm. follow-the-sun-model lack of ad-hoc comm. exible work hours restricted comm. reduce intersite-comm. nd right comm. media for each situation multiple comm. models less shared proj. awaren. presence awaren. tools (e.g. MS Lync) face-to-face meetings or video-conferences exchange specialists buddy-system poor knowledge-mgn. knowledge transfer mechanisms poor documentation dene standards for documentation nd responsible person few core-developers visible work-progress (see proj. awaren.) share same environment e.g. MS Lync, MS TFS language barriers consistent language non-native speakers choose comm. channel cultural di. complementary people in same team address problems early train cultural awaren. dierent experience check, train, convey experience resistance prevent development of rivalry address conicts systematically allocate tasks trust convey trust arrange informal meetings team-feeling reduce team cohesion create team-spirit higher risks clearly dene roles + resp. develop dicult tasks in-house develop time-intensive tasks in-house coordination milestones, clear proj. denition tracking, control developer is responsible for subtask asymmetry in processes, eective policies for condentiality, copypolicies, standards right protection, intellectual property change mgn. no selected study proposed a solution infrastructure incomp. meticulous planning ensure infrastrucutre compatibility among geographic locations incomp. standards dene overall standards DSD tools CAMEL, TAMRI, NEXTMOVE, MS Lync, MS TFS traditional tools paper [1,5] [1] [13] [6] [7] [13] [2] [5] [1,17] [3,11] [8] [13] [8,3] [6] [3] [17,18] [5] [5] [15] [4] [4,3] [7] [4] [6,7] [7] [8] [1] [5] [4,3] [7] [7] [5,8] [6] [3] [2] [3]

ind.

mgn.

tech.

[4,17, 18] [11]

Table 1. A comparison of the main challenges and selected solutions.

13

emerging due to the usage of these tools. Furthermore, not every problem can be solved by tools, e.g. cultural dierences. Again, a proper study of the right usage of the tools at the beginning of the project may reduce such problems and improve quality. All the factors mentioned in this paper assign a huge responsibility to the management, which has to minimize the risks. Although lots of problems such as change management and risk management were addressed, almost no solutions were presented in the selected studies. There is denitely a need of further research on this topic, but there obviously are scenarios, in which DSD may work for large software projects and may be just as ecient and eective as collocated development.

Conclusions

The two basic questions, which are dened in chapter 1, are answered within this report: the motivation to develop software in a distributed way as well as a selection of challenges and solutions are described and reected. As the globalization trend surges forward, only a few software engineers and developers will remain unaected [2]. The increasing importance of DSD has several reasons which are discussed in this report. In most cases, enterprises distribute in order to save money due to lower labour costs. Firms can (dramatically) reduce their development times by learning to overlap activity across stages [9]. Low-cost countries such as China or India oer thousands of educated developers with experience in developing in a distributed environment. In some countries, it is also dicult to nd skilled people and moreover, some customers require their consignee to work at their place. Working in a distributed situation is dicult and requires a good knowledge of worldwide markets [7]. DSD is a high risk business and may cause a lot of troubles. Miscommunication is a problem that often occurs in such situations, leading to misunderstanding, dissatisfaction and rising costs. It is important to reduce language barriers, nd the right communication media (synchronous or asynchronous, formal or informal) for each situation and to generate awareness, trust and a sense of belonging to a team. Time-zone dierences and the lack of ad-hoc communication as well as cultural problems may further disturb communication and may make it dicult to nd the right information when needed. The management is another burden and it is dicult to keep the overview of distributed projects and to assign tasks to the right people. Interestingly, most projects are handled without the use of special tools, but they heavily rely on traditional tools such as e-mail, instant messaging, video-conference and telephone. In order to develop a product of high quality and sustainability, it is important that the mentioned challenges are taken serious. Furthermore, each company has to elaborate the best degree of distribution and corresponding solutions itself.

14

References
[1] Bird, C., Nagappan, N., Devanbu, P., Gall., H., Murphy, B.: Does Distributed Development Aect Software Quality? An Empirical Case Study of Windows Vista, Software Engineering, 2009. ICSE 2009. IEEE 31st International Conference on Software Engineering, pp. 518-528, Davis, California (2009). Herbsleb, J.D., Moitra, D.: Introduction: Global software development, Software, IEEE, vol. 18, no. 2, pp. 16-20 (2001). Venolia, G., Tang, J., Cervantes, R., Bly, S., Robertson, G.: Embodied Social Proxy: Mediating Interpersonal Connection in Hub-and-Satellite Teams, Association for Computing Machinery, Inc., Georgia, USA (2010). da Silva, F.Q.B., Costa, C., Frana, A.C.C., Prikladinicki, R: Challenges and Solutions in Distributed Software Development Project Management: A Systematic Literature Review, Global Software Engineering (ICGSE), 2010 5th IEEE International Conference on, Recife, Brazil, pp. 87-96 (2010) Prikladnicki, R., Audy, J.L.N., Damian, D., de Oliveira, T.C.: Distributed Software Development: Practices and challenges in dierent business strategies of oshoring and onshoring, Global Software Engineering, 2007. ICGSE 2007. Second IEEE International Conference on Global Software Engineering, Catolica do Rio Grande do Sul, Porto Alegre, pp. 262-274 (2007). Gutwin, C., Penner, R., Schneider, K.: Group Awareness in Distributed Software Development, CSCW 04 Proceedings of the 2004 ACM conference on Computer supported cooperative work, Saskatoon, Canada, pp. 72-81 (2004). Lamersdorf, A., Munch, J., Rombach, D.: A Survey on the State of the Practice in Distributed Software Development: Criteria for Task Allocation, Global Software Engineering, 2009. ICGSE 2009. Fourth IEEE International Conference on, Kaiserslautern, Germany (2009). Herbsleb, J.D., Grinter, R.E.: Architectures, coordination, and distance: Conways law and beyond, Software, IEEE, vol. 16, no. 5, pp. 63-70, Naperville, USA (1999). Blackburn, J.D., Hoedemaker, G., Van Wassenhove, L.N.: Concurrent Software Engineering: Prospects and Pitfalls, IEEE transactions on engineering management, vol. 43, no. 2, pp. 179-188 (1996). Herbsleb, J.D., Mockus A.: Challenges of global software development, Software Metrics Symposium, 2001. METRICS 2001. Proceedings. Seventh International Software Metrics Symposium, Naperville, USA, pp. 182-184 (2001). Al-Ani, B., Edwards, H.K.: A Comparative Empirical Study of Communication in Distributed and Collocated Development Teams, In the proceedings of the 2008 IEEE International Conference on Global Software Engineering, pp. 35-44 (2008). Raymond, E.: The Cathedral and the Bazaar, (2000). Holmstrom, H., Conchuir, E.O., Agerfalk, P.J., Fitzgerald, B.: Global Software Development Challenges: A Case Study on Temporal, Geographical and SocioCultural Distance Proceedings of the IEEE International Conference on Global Software Engineering, ICGSE06, vol. 0, pp. 3-11 (2006). Liang, X., Ma, X., Yang, Q., Zhuo, Y., Xu, B., Ma, A.: A Virtual Human Resource Organization Model in Dual-shore Collaborative Software Development, International Conference on Wireless Communications, Networking and Mobile Computing, 2008. WiCOM 08. 4th, (2008).

[2] [3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12] [13]

[14]

15 [15] Krishna, S., Sahay, S., Walsham, G.: Managing cross-cultural issues in global software outsourcing, Communications of the ACM - Human-computer etiquette, vol. 47, iss. 4 (2004). Bohem, B.:A View of 20th and 21st Century Software Engineering, Proceedings of 28th ICSE, Shanghai (2006). Microsoft Lync, http://lync.microsoft.com, last visited: 01.12.2011. Visual Studio, Team Foundation Server, http://www.microsoft.com/visualstudio/enus/products/2010-editions/team-foundation-server/overview, last visited: 01.12.2011.

[16] [17] [18]