Governing individual learning in the transition phase of software maintenance offshoring: a dynamic perspective

Prior studies suggest that clients need to actively govern knowledge transfer to vendor staff in offshore outsourcing. In this paper, we analyze longitudinal data from four software maintenance offshore out-sourcing projects to explore why governance may be needed for knowledge transfer and how governance and the individual learning of vendor engineers inter-act over time. Our results suggest that self-control is central to learning, but may be hampered by low levels of trust and expertise at the outset of projects. For these foundations to develop, clients initially need to exert high amounts of formal and clan controls to enforce learning activities against barriers to knowledge sharing. Once learning activities occur, trust and expertise increase and control portfolios may show greater emphases on self-control.

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.

Knowledge transfer in software-maintenance offshore outsourcing

Software-maintenance offshore outsourcing (SMOO) projects have been plagued by tedious knowledge transfer during the service transition to the vendor. Vendor engineers risk being over-strained by the high amounts of novel information, resulting in extra costs that may erode the business case behind offshoring. Although stakeholders may desire to avoid these extra costs by implementing appropriate knowledge transfer practices, little is known on how effective knowledge transfer can be designed and managed in light of the high cognitive loads in SMOO transitions. The dissertation at hand addresses this research gap by presenting and integrating four studies. The studies draw on cognitive load theory, attributional theory, and control theory and they apply qualitative, quantitative, and simulation methods to qualitative data from eight in-depth longitudinal cases. The results suggest that the choice of appropriate learning tasks may be more central to knowledge transfer than the amount of information shared with vendor engineers. Moreover, because vendor staff may not be able to and not dare to effectively self-manage learn-ing tasks during early transition, client-driven controls may be initially required and subsequently faded out. Collectively, the results call for people-based rather than codification-based knowledge management strategies in at least moderately specific and complex software environments.

Managing Knowledge Transfer in Software-Maintenance Outsourcing Transitions: A System-Dynamics Perspective

The existing literature suggests that transitions in software-maintenance offshore outsourcing projects are prone to knowledge transfer blockades, i.e. situations in which the activities that would yield effective knowledge transfer do not occur, and that client management involvement is central to overcome them. However, the theoretical understanding of the knowledge transfer blockade is limited, and the reactive management behavior reported in case studies suggests that practitioners may frequently be astonished by the dynamics that may give rise to the blockade. Drawing on recent research from offshore sourcing and reference theories, this study proposes a system dynamics framework that may explain why knowledge transfer blockades emerge and how and why client management can overcome the blockade. The results suggest that blockades may emerge from a vicious circle of weak learning due to cognitive overload of vendor staff and resulting negative ability attributions that result in reduced helping behavior and thus aggravate cognitive load. Client management may avoid these vicious circles by selecting vendor staff with strong prior related experience. Longer phases of coexistence of vendor staff and subject matter experts and high formal and clan controls may also mitigate vicious circles.

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.

Software Cartography: Thematic Software Visualization with Consistent Layout

Software visualizations can provide a concise overview of a complex software system. Unfortunately, as software has no physical shape, there is no `natural' mapping of software to a two-dimensional space. As a consequence most visualizations tend to use a layout in which position and distance have no meaning, and consequently layout typically diverges from one visualization to another. We propose an approach to consistent layout for software visualization, called Software Cartography, in which the position of a software artifact reflects its vocabulary, and distance corresponds to similarity of vocabulary. We use Latent Semantic Indexing (LSI) to map software artifacts to a vector space, and then use Multidimensional Scaling (MDS) to map this vector space down to two dimensions. The resulting consistent layout allows us to develop a variety of thematic software maps that express very different aspects of software while making it easy to compare them. The approach is especially suitable for comparing views of evolving software, as the vocabulary of software artifacts tends to be stable over time. We present a prototype implementation of Software Cartography, and illustrate its use with practical examples from numerous open-source case studies.

Analyzing Software Evolution through Feature Views

Features encapsulate the domain knowledge of a software system and thus are valuable sources of information for a reverse engineer. When analyzing the evolution of a system, we need to know how and which features were modified to recover both the change intention and its extent, namely which source artifacts are affected. Typically, the implementation of a feature crosscuts a number of source artifacts. To obtain a mapping between features to the source artifacts, we exercise the features and capture their execution traces. However this results in large traces that are difficult to interpret. To tackle this issue we compact the traces into simple sets of source artifacts that participate in a feature's runtime behavior. We refer to these compacted traces as feature views. Within a feature view, we partition the source artifacts into disjoint sets of characterized software entities. The characterization defines the level of participation of a source entity in the features. We then analyze the features over several versions of a system and we plot their evolution to reveal how and hich features were affected by changes in the code. We show the usefulness of our approach by applying it to a case study where we address the problem of merging parallel development tracks of the same system.

Tackling Software Navigation Issues of the Smalltalk IDE

The IDE used in most Smalltalk dialects such as Pharo, Squeak or Cincom Smalltalk did not evolve significantly over the last years, if not to say decades. For other languages, for instance Java, the available IDEs made tremendous progress as Eclipse or NetBeans illustrate. While the Smalltalk IDE served as an exemplar for many years, other IDEs caught up or even overtook the erstwhile leader in terms of feature-richness, usability, or code navigation facilities. In this paper we first analyze the difficulty of software navigation in the Smalltalk IDE and second illustrate with concrete examples the features we added to the Smalltalk IDE to fill the gap to modern IDEs and to provide novel, improved means to navigate source space. We show that thanks to the agility and dynamics of Smalltalk, we are able to extend and enhance with reasonable effort the Smalltalk IDE to better support software navigation, program comprehension, and software maintenance in general. One such support is the integration of dynamic information into the static source views we are familiar with. Other means include easing the access to static information (for instance by better arranging important packages) or helping developers re-locating artifacts of interest (for example with a categorization system such as smart groups).

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.