«This research has been partially sponsored by the Dutch Joint Academic and Commer- cial Quality Research & Development (Jacquard) program on Software ...»
In the discussion, we focus on the contribution of architectural rules to the handling of GSD issues. Finally, §4.5 lists our conclusions.
4.2 Related Work This section provides related work in the ﬁeld of software architecture, the concept of architectural rules, and general challenges identiﬁed in global software development literature.
Recently, software architecture is regarded as the set of architectural design decisions (Jansen and Bosch, 2005; Kruchten et al., 2006). Examples of these decisions include preferred or mandatory standards on communication between layers of the architecture or datastructure conventions. Those architectural decisions that must be complied with throughout the organization are deﬁned as architectural rules (Boasson, 1995; Clerc et al., 2007a). Architectural rules can help to overcome challenges in software engineering and software architecture (Boasson, 1995). However, we lack insight into what rules are necessary to guide GSD.
A software architecture imposes coordination and communication efforts between development teams that are necessary to successfully implement the architecture. To minimize these efforts, the software architecture often mimics the structure of the organization: a certain modular architectural design is used as the basis to distribute development work across different teams (Conway, 1968). With GSD, the challenge to distribute work becomes even bigger. As development work is spread across development sites, (Herbsleb and Mockus, 2003) indicate that this demands which demands more coordination and communication effort.
As we have shown in Chapter 3, having a description of the software architecture and rules on the architecture alone is not enough to ensure successful compliance in GSD. These rules should be accompanied by additional process guidelines and activities to let them sink in properly. These additional guidelines and activities pertain to the use
58 4.3. Challenges in Global Software Development
and personalization of architectural rules as opposed to codiﬁcation that often receives most emphasis (Hansen et al., 1999; Desouza et al., 2006).
Substantial work has been done to provide insight into the problems or challenges that occur when the development effort is spread across multiple development sites (Herbsleb and Grinter, 1999a; Herbsleb et al., 2005). Herbsleb et al. (2001) list several dimensions of the problem with physical separation of software engineering practitioners: technical problems, project management problems, knowledge management problems, and communication problems. Socio-cultural, temporal, and geographical issues ˚ are further exempliﬁed in (Agerfalk et al., 2005; Holmstr¨ m et al., 2006).
o Some solutions to overcome the challenges involved in GSD are also addressed in the literature. Herbsleb and Grinter (1999a) report on several solutions to overcome the distance innate to GSD, such as attending to Conway’s Law (Conway, 1968), travelling at the start of projects to get to know relevant individuals from multiple sites upfront, and recording architectural design decisions including their rationale. Corry et al.
(2006) describe a technique in which architects frequently travel between development sites to engage developers in software architecture work. Bass (2006) proposes an approach in which collaborating practitioners ﬁrst acquire a mental model of the software engineering task they need to perform (Espinoza et al., 2002), and only then pursue completion of the task. The signiﬁcance of a shift in perspective is signalled in (Bass, 2006): project management should pay more attention to coordination problems and applied synchronization efforts. Other work of Bass et al. relates the required communication and coordination efforts in software engineering (Herbsleb and Mockus, 2003) to the organization’s capabilities (Bass et al., 2007b). Problems occur when the required communication and coordination efforts exceed the organization’s capabilities. This results in misalignment between the architectural design decisions that have been taken and the organizational structure (Bass et al., 2007b). Since communication and coordination efforts are more important when an organization is involved in GSD, these efforts place additional requirements to the organization’s capabilities.
4.3 Challenges in Global Software Development In this section, we list four global software development challenges we have distilled from the literature (see Sections 4.3.1 through 4.3.4). We took proceedings from relevant conferences and workshops (the GSD and ICGSE proceedings) and special issues of magazines (e.g., special issues in IEEE Software), both on the topic of GSD, as a basis. We next identiﬁed the issues described in these contributions and grouped and related them when possible. Fig. 4.1 provides an overview. For some of the challenges, we made a further subdivision, to ﬁnally end up with a list of seven issues. As the ﬁgure shows, challenges can amplify other challenges. The remainder of this section describes these challenges, issues, and their interrelations. For each issue, examples of possible solutions are given. We primarily focus on solutions that pertain to the architecture, but mention other solutions when these are not available.
4.3.1 Challenge 1: Time difference and geographical distance The ﬁrst challenge in global software development originates from the innate difference with GSD as compared to collocated software development: working at geographical distant sites and the time difference incurred. Geographical distance and time difference burden software engineering activities. Software engineering activities are knowledgeintensive tasks and therefore require communication during various phases in the lifecycle (Herbsleb and Mockus, 2003). Time difference leads to delays because of less overlapping working hours (Herbsleb and Grinter, 1999a). Furthermore, geographical distance leads to delays because it increases the unresponsiveness of practitioners.
This challenge ampliﬁes that of culture (Challenge 2), as empirically investigated by (Herbsleb and Mockus, 2003). Differences exist in how this ampliﬁcation exactly occurs: cultural differences may exist within the same time zone due to large geographical distance (e.g., UK and South-Africa collaborating) and, conversely, cultural similarities may exist between practitioners from countries with a large geographical distance.
4.3.2 Challenge 2: Culture GSD involves software engineers, software architects, and other practitioners, possibly from all over the globe. People with different cultural backgrounds are required to cooperate in order to deliver working software in time. As shown by (Hofstede, 2001), people with different cultural backgrounds behave differently. We have examined literature on cultural challenges and identiﬁed the issue that is regarded as key for supporting
software engineering practices in a GSD setting:
1. Difﬁculty to initiate contact Establishing contact between practitioners of different cultures faces additional challenges as compared to establishing contact between practitioners of the same culture
(Hofstede, 2001). Moreover, the challenge of culture is ampliﬁed when project members located at different development sites want to initiate contact (Herbsleb and Grinter, 1999a). Examples of cultural problems include limitations in the vocabulary of practitioners (Holmstr¨ m et al., 2006) and difference in communication style: reluctance to o ask questions (Herbsleb et al., 2005), direct versus indirect communication (e.g., phone versus email) (Herbsleb and Grinter, 1999b), or giving preference to sending an e-mail over establishing contact directly by phone (Herbsleb and Grinter, 1999a).
Grinter et al. (1999) and Herbsleb et al. (2005) indicate that the main solution to overcome this cultural issue may be to establish face-to-face contact and to get to know ‘who is who’ in the project. Suggestions that can help to overcome this issue are 1) establish a directory listing all practitioners involved in the development of certain parts of the architecure and 2) start all projects with a kick-off meeting. Establishing contact is easier when practitioners are located at the same development site. Once contact has been initiated, practitioners are more willing to overcome their cultural differences in order to communicate effectively.
The cultural challenge described in this section inﬂuences or ampliﬁes other GSD challenges, such as communication challenges, collaboration challenges, and work distribution challenges.
4.3.3 Challenge 3: Team communication and collaboration The nature of global software development results in increased difﬁculties to communicate and collaborate within teams and between teams involved in software development.
We distilled the following issues from literature addressing this challenge:
2. Difﬁculty to exchange information
3. Difference in sense of urgency
4. Difﬁculty to build a team
5. No collective ownership Difﬁculty to exchange information Having teams at geographically separated sites results in a lack of unplanned, informal contact during which seemingly irrelevant but in fact highly valuable information is exchanged (Herbsleb and Grinter, 1999a; Herbsleb and Mockus, 2003). The information exchanged during unplanned social meetings is not necessarily architectural in nature, but can help to more easily obtain architectural information. Moreover, unplanned social meetings help people to build awareness of what will happen before a formal decision is made. In particular, awareness of architectural design decisions is important, since these decisions may have a high impact across development sites. In addition, the difﬁculty to exchange information arises at an early stage in the project, because practitioners just do not know who to contact at a remote site; they simply don’t know the practitioners at a remote site (see Challenge 2).
A number of suggestions to lower the threshold to exchange information across different development sites have been provided in the literature. These suggestions include
614. Reassessing the Need for Practices for Architectural Compliance
providing incentives to improve collaboration and knowledge sharing. To improve collaboration, teams of experts or communities of practice (Herbsleb et al., 2005), in which gurus can ﬂourish, can be established. Incentives for architectural knowledge sharing include the establishment of social ties and knowledge internalization (Farenhorst et al., 2007c). Other suggestions to address the difﬁculty of exchanging information include traveling to different development sites at an early stage in the project and meeting various practitioners at these sites. As a result of the face-to-face contact, practitioners experience that there actually is “a person behind an email address” (Herbsleb et al., 2005). This effect can be achieved by processes and policies regulating the frequency, location, and participants of the required inter-site meetings.
Difference in sense of urgency GSD can result in a difference in the sense of urgency across development sites to handle speciﬁc requests. A difference in establishing contact on a certain topic (e.g., practitioners prefer to send someone an email over calling that person) inﬂuences the sense of urgency to handle that topic. As with the previous issue, getting to know practitioners from other sites is key to overcoming this issue. Once a key individual is already known to practitioners at another site, these practitioners are more willing to pose a question to that individual. This person can even become a liaison, or ﬁrst contact point for practitioners at the other site (Herbsleb et al., 2001). Communication is sped up, development activities to be performed are agreed upon, and a collective sense of urgency towards the activities that need to be performed is achieved. This collective sense of urgency, in turn, will shorten development time. Measures that focus on the development process can be of value in this case. An architectural rule could make explicit that every project, site, or subsystem should have a liaison. Additional information on how, when, and where to contact this liaison could be provided as well.
Difﬁculty to build a team Now that we have seen possible solutions to address the difﬁculties of exchanging information and the difference in sense of urgency, we face another difﬁculty: it is difﬁcult to build up a single, virtual team across development sites because this is hampered by the geographic distance and time difference (Herbsleb and Mockus, 2003; Dekker, 2008) (see Challenge 1). A single, virtual team is characterized by low communication thresholds and high collaboration possibilities. Not having such a team results in possible mismatches in terminology and deﬁnitions and, consequently, communication overhead and delays (Herbsleb et al., 2001).
A possible solution to the issue of building a team is to develop architectural rules that contain conventions and procedures on collaboration and the use of a single, shared environment (e.g., when to check in source code, how to build and name a release).
These rules then are disseminated across the involved development sites.
In order to build a single, virtual team the effectiveness of communication across development sites should be high. Two possible approaches to improve effectiveness
are discussed below:
• First, as a preventive measure, it is possible to reduce the amount of communication across development sites by aligning the organizational structure with the software architecture (Conway, 1968). This requires that the architecture is ﬁxed
(or, sufﬁciently ﬁxed) to distribute the work and have development sites operate in parallel. In §4.3.4 we will further delve into this subject.