Explaining Variations in Client Extra Costs between Software Projects Offshored to India

Gaining economic benefits from substantially lower labor costs has been reported as a major reason for offshoring labor-intensive information systems services to low-wage countries. However, if wage differences are so high, why is there such a high level of variation in the economic success between offshored IS projects? This study argues that offshore outsourcing involves a number of extra costs for the ^his paper was recommended for acceptance by Associate Guest Editor Erran Carmel. client organization that account for the economic failure of offshore projects. The objective is to disaggregate these extra costs into their constituent parts and to explain why they differ between offshored software projects. The focus is on software development and maintenance projects that are offshored to Indian vendors. A theoretical framework is developed a priori based on transaction cost economics (TCE) and the knowledge-based view of the firm, comple mented by factors that acknowledge the specific offshore context The framework is empirically explored using a multiple case study design including six offshored software projects in a large German financial service institution. The results of our analysis indicate that the client incurs post contractual extra costs for four types of activities: (1) re quirements specification and design, (2) knowledge transfer, (3) control, and (4) coordination. In projects that require a high level of client-specific knowledge about idiosyncratic business processes and software systems, these extra costs were found to be substantially higher than in projects where more general knowledge was needed. Notably, these costs most often arose independently from the threat of oppor tunistic behavior, challenging the predominant TCE logic of market failure. Rather, the client extra costs were parti cularly high in client-specific projects because the effort for managing the consequences of the knowledge asymmetries between client and vendor was particularly high in these projects. Prior experiences of the vendor with related client projects were found to reduce the level of extra costs but could not fully offset the increase in extra costs in highly client-specific projects. Moreover, cultural and geographic distance between client and vendor as well as personnel turnover were found to increase client extra costs. Slight evidence was found, however, that the cost-increasing impact of these factors was also leveraged in projects with a high level of required client-specific knowledge (moderator effect).

Explaining Endogenous Control Change in Outsourced Software Projects

Given the centrality of control for achieving success in outsourced software projects, past research has identified key exogenous factors that determine the choice of controls. This view of exogenously driven control choice is based on a number of assumptions; particularly, clients and vendors are seen as separate cognitive entities that combat opportunistic threats under environmental uncertainty by one-off choices or infrequent revisions of controls. In this paper we complement this perspective by acknowledging that an outsourced software project may be characterized as a collective, evolving process faced with the challenge of coping with cognitive limitations of both client and vendor through a continuous process of learning. We argue that if viewed in this way, controls are less subject of a deliberate choice but rather are subject of endogenously driven change, i.e. controls evolve in close interaction with the evolving software project. Accordingly, we suggest a complementary model of endogenous control, where controls mediate individual and collective learning processes. Our research contributes to a better understanding of the dynamics in outsourced software projects. It also spells out methodological implications that may help improve cross-section control research.

Knowledge in software-maintenance outsourcing projects: beyond integration of business and technical knowledge

Knowledge processes are critical to outsourced software projects. According to outsourcing research, outsourced software projects succeed if they manage to integrate the client’s business knowledge and the vendor’s technical knowledge. In this paper, we submit that this view may not be wrong, but incomplete in a significant part of outsourced software work, which is software maintenance. Data from six software-maintenance outsourcing transitions indicate that more important than business or technical knowledge can be application knowledge, which vendor engineers acquire over time during practice. Application knowledge was the dominant knowledge during knowledge transfer activities and its acquisition enabled vendor staff to solve maintenance tasks. We discuss implications for widespread assumptions in outsourcing research.

Comparative Analysis of Evolving Software Systems Using the Gini Coefficient

Software metrics offer us the promise of distilling useful information from vast amounts of software in order to track development progress, to gain insights into the nature of the software, and to identify potential problems. Unfortunately, however, many software metrics exhibit highly skewed, non-Gaussian distributions. As a consequence, usual ways of interpreting these metrics --- for example, in terms of "average" values --- can be highly misleading. Many metrics, it turns out, are distributed like wealth --- with high concentrations of values in selected locations. We propose to analyze software metrics using the Gini coefficient, a higher-order statistic widely used in economics to study the distribution of wealth. Our approach allows us not only to observe changes in software systems efficiently, but also to assess project risks and monitor the development process itself. We apply the Gini coefficient to numerous metrics over a range of software projects, and we show that many metrics not only display remarkably high Gini values, but that these values are remarkably consistent as a project evolves over time.

Package Patterns for Visual Architecture Recovery

Recovering the architecture is the first step towards reengineering a software system. Many reverse engineering tools use top-down exploration as a way of providing a visual and interactive process for architecture recovery. During the exploration process, the user navigates through various views on the system by choosing from several exploration operations. Although some sequences of these operations lead to views which, from the architectural point of view, are mode relevant than others, current tools do not provide a way of predicting which exploration paths are worth taking and which are not. In this article we propose a set of package patterns which are used for augmenting the exploration process with in formation about the worthiness of the various exploration paths. The patterns are defined based on the internal package structure and on the relationships between the package and the other packages in the system. To validate our approach, we verify the relevance of the proposed patterns for real-world systems by analyzing their frequency of occurrence in six open-source software projects.

Augmenting Static Source Views in IDEs with Dynamic Metrics

Mainstream IDEs such as Eclipse support developers in managing software projects mainly by offering static views of the source code. Such a static perspective neglects any information about runtime behavior. However, object-oriented programs heavily rely on polymorphism and late-binding, which makes them difficult to understand just based on their static structure. Developers thus resort to debuggers or profilers to study the system's dynamics. However, the information provided by these tools is volatile and hence cannot be exploited to ease the navigation of the source space. In this paper we present an approach to augment the static source perspective with dynamic metrics such as precise runtime type information, or memory and object allocation statistics. Dynamic metrics can leverage the understanding for the behavior and structure of a system. We rely on dynamic data gathering based on aspects to analyze running Java systems. By solving concrete use cases we illustrate how dynamic metrics directly available in the IDE are useful. We also comprehensively report on the efficiency of our approach to gather dynamic metrics.

Knowledge Transfer Processes in the IS Offshore Outsourcing Transition: A Conceptual Model

Despite promising cost saving potential, many offshore software projects fail to realize the expected benefits. A frequent source of failure lies in the insufficient transfer of knowledge during the transition phase. Former literature has reported cases where some domains of knowledge were successfully transferred to vendor personnel whereas others were not. There is further evidence that the actual knowledge transfer processes often vary from case to case. This raises the question whether there is a systematic relationship between the chosen knowledge transfer process and know-ledge transfer success. This paper introduces a dynamic perspective that distinguishes different types of knowledge transfer processes explaining under which circumstances which type is deemed most appropriate to successfully transfer knowledge. Our paper draws on knowledge transfer literature, the Model of Work-Based Learning and theories from cognitive psychology to show how characteristics of know-ledge and the absorptive capacity of knowledge recipients fit particular knowledge transfer processes. The knowledge transfer processes are conceptualized as combinations of generic knowledge transfer activities. This results in six gestalts of know-ledge transfer processes, each representing a fit between the characteristics of the knowledge process and the characteristics of the knowledge to be transferred and the absorptive capacity of the knowledge recipient.

Learning software-maintenance tasks in offshoring projects: a cognitive-load perspective

Individual learning is central to the success of the transition phase in software mainte-nance offshoring projects. However, little is known on how learning activities, such as on-the-job training and formal presentations, are effectively combined during the tran-sition phase. In this study, we present and test propositions derived from cognitive load theory. The results of a multiple-case study suggest that learning effectiveness was highest when learning tasks such as authentic maintenance requests were used. Con-sistent with cognitive load theory, learning tasks were most effective when they imposed moderate cognitive load. Our data indicate that cognitive load was influenced by the expertise of the onsite coordinator, by intrinsic task complexity, by the degree of specifi-cation of tasks, and by supportive information. Cultural and semantic distances may in-fluence learning by inhibiting supportive information, specification, and the assignment of learning tasks.

Learning Software-Maintenance Tasks in the Transition Phase of Offshore Outsourcing Projects: Two Learning-Theoretical Perspectives

The increasing practice of offshore outsourcing software maintenance has posed the challenge of effectively transferring knowledge to individual software engineers of the vendor. In this theoretical paper, we discuss the implications of two learning theories, the model of work-based learning (MWBL) and cognitive load theory (CLT), for knowledge transfer during the transition phase. Taken together, the theories suggest that learning mechanisms need to be aligned with the type of knowledge (tacit versus explicit), task characteristics (complexity and recurrence), and the recipients’ expertise. The MWBL proposes that learning mechanisms need to include conceptual and practical activities based on the relative importance of explicit and tacit knowledge. CLT explains how effective portfolios of learning mechanisms change over time. While jobshadowing, completion tasks, and supportive information may prevail at the outset of transition, they may be replaced by the work on conventional tasks towards the end of transition.

The Small Project Observatory: Visualizing Software Ecosystems

Software evolution research has focused mostly on analyzing the evolution of single software systems. However, it is rarely the case that a project exists as standalone, independent of others. Rather, projects exist in parallel within larger contexts in companies, research groups or even the open-source communities. We call these contexts software ecosystems, and on this paper we present The Small Project Observatory, a prototype tool which aims to support the analysis of project ecosystems through interactive visualization and exploration. We present a case-study of exploring an ecosystem using our tool, we describe about the architecture of the tool, and we distill the lessons learned during the tool-building experience.

Hot Clones, Maintaining a Link Between Software Clones Across Repositories

Code duplication is common in current programming-practice: programmers search for snippets of code, incorporate them into their projects and then modify them to their needs. In today's practice, no automated scheme is in place to inform both parties of any distant changes of the code. As code snippets continues to evolve both on the side of the user and on the side of the author, both may wish to benefit from remote bug fixes or refinements --- authors may be interested in the actual usage of their code snippets, and researchers could gather information on clone usage. We propose maintaining a link between software clones across repositories and outline how the links can be created and maintained.

Replaying past changes in multi-developer projects

What was I working on before the weekend? and What were the members of my team working on during the last week? are common questions that are frequently asked by a developer. They can be answered if one keeps track of who changes what in the source code. In this work, we present Replay, a tool that allows one to replay past changes as they happened at a fine-grained level, where a developer can watch what she has done or understand what her colleagues have done in past development sessions. With this tool, developers are able to not only understand what sequence of changes brought the system to a certain state (e.g., the introduction of a defect), but also deduce reasons for why her colleagues performed those changes. One of the applications of such a tool is also discovering the changes that broke the code of a developer.

Lessons in Software Evolution Learned by Listening to Smalltalk

The biggest challenge facing software developers today is how to gracefully evolve complex software systems in the face of changing requirements. We clearly need software systems to be more dynamic, compositional and model-centric, but instead we continue to build systems that are static, baroque and inflexible. How can we better build change-enabled systems in the future? To answer this question, we propose to look back to one of the most successful systems to support change, namely Smalltalk. We briefly introduce Smalltalk with a few simple examples, and draw some lessons for software evolution. Smalltalk's simplicity, its reflective design, and its highly dynamic nature all go a long way towards enabling change in Smalltalk applications. We then illustrate how these lessons work in practice by reviewing a number of research projects that support software evolution by exploiting Smalltalk's design. We conclude by summarizing open issues and challenges for change-enabled systems of the future.