This paper reports on detailed observations during software enhancement tasks of five programmers enhancing software. The enhancement tasks represent realistic work behavior by industrial programmers. The paper describes the kinds of actions programmers preferred during their task, the level of abstraction at which they were working, and the role of hypotheses in their enhancement strategies. 1 Introduction Understanding software is an important aspect of software maintenance. To enhance performance, add new features, or leverage existing code, a programmer must understand the code well enough to know what changes are needed, how to make them, and how to integrate new code into existing applications. For larger software products, understanding will, by necessity, be partial. Software products typically evolve through successive enhancements. These enhancements vary in size and complexity. Some programmers develop deep knowledge of a product through several enhancement cycles, others ...

Hypotheses are major drivers of program comprehension. We report on a case study observing an experienced software engineer porting a large software system and the role of hypotheses in accomplishing the porting task. Observations confirm some existing theoretic models and experimental findings, but not all. While generalization based on a case study is of necessity limited, the results could be the basis for further experiments. They also point to information that would help novices to become experts faster. 1 Introduction Hypotheses have long been recognized as major drivers of program comprehension [3, 1]. They help to direct further investigation. Generating hypotheses about code and investigating whether they hold or must be rejected is an important facet of code understanding. Letovsky [3] defines Hypotheses as conjectures and comprehension activities (actions) that take on the order of seconds or minutes to occur. Actions classify programmer activities, both implicit and expli...

Clustering of the entities composing a Web application (static and dynamic pages) can be used to support program understanding. However, several alternative options are available when a clustering technique is designed for Web applications. The entities to be clustered can be described in different ways (e.g., by their structure, by their connectivity, or by their content), different similarity measures are possible, and alternative procedures can be used to form the clusters. The problem is how to evaluate the competing clustering techniques, in order to select the best for program understanding purposes. In this paper, two methods for clustering evaluation are considered, the gold standard and the task oriented approach. The advantages and disadvantages of both of them are analyzed in detail. Definition of a gold standard (reference clustering) is difficult and prone to subjectivity. On the other side, an evaluation based on the level of support given to task execution is expensive and requires careful experimental design. Guidelines and examples are provided for the implementation of both methods. 1

The decision on whether to proceed top-down or bottomup during software development has a strong and underestimated impact on the quality of the final product including its later evolvability. Various examples for both strategies taken from such different domains as operating systems and computer games provide evidence that bottom-up developed systems are more suitable for future evolution. The reasons for this range from the increased compositionality of bottom-up developed artefacts at the technical level up to a greater independence from certain requirements which constitute the most transient part of a software system. Besides those advantages concerning evolvability, the negative effects of bottom-up orientation can not be ignored. Furthermore, proceeding bottom-up contradicts most conventional development processes. We regard this as a clear indication for the need of new development processes to improve the construction of evolvable software. 1. Processes Influence Evolvability

Changeability (also called evolvability) is an essential property of software. Software change is the foundation for both new software development and legacy software maintenance, therefore a better understanding of software change is an important software engineering issue. This paper covers selected topics related to software change, including minicycle of change, partitioned annotations, and change propagation, and gives a brief overview of the field. 1

Spatial cognition and program development have both been examined using contrasting models. We suggest that sex-based differences in one’s perception of risk is the key to relating these models. Specifically, the survey map approach to navigation and the top-down development/comprehension strategy use similar and related high risk cognitive skills that males show a preference towards. Conversely, the route-based approach to navigation and the bottom-up development/comprehension strategy use similar and related low risk cognitive skills that women show a preference towards. On the assumption that programmers are consistent in their risk-taking behaviours, we believe that they will, as much as possible, tend to use the same strategy when performing program development and comprehension. In an experimental setting, we compare programmer’s performance on spatial cognition and program comprehension tasks. The correlations that we found suggest that programmers use equivalently risky strategies for program comprehension and spatial cognition. Thus, there is evidence that similar cognitive skills are used for spatial cognition and program comprehension/development, and that the similarities are a consequence of sex-based differences in risk-taking behaviour. 1

Newcomer and expert programmers often interact with development artifacts differently. Ideally, software development tools should support these different styles of work. In this paper, we describe our investigations into the interaction difference between newcomers and experts, regarding two properties that characterize repetition of programmer interaction: temporal locality and interaction coupling recurrence. We describe our approach, research questions and planned methodology.

Objective: To ascertain whether programmers gain more knowledge about an unfamiliar program by enhancing the code or documenting the code. The context of this work was investigating whether maintenance programmers faced with an unfamiliar system should start by actively working on the system or spend time passively exploring the system before attempting to make changes. Method: We designed a laboratory experiment where subjects initially either enhanced or documented a program and then we measured how they performed when carrying out a further task on the given code. Our hypothesis was that programmers would gain more knowledge performing one of the two tasks. The experiment was repeated three times with different groups of students, all at the same stage of their education. Results: There was no significant difference between the performance of the two groups who had performed different initial tasks. However, there was a strong correlation between performance in the measured task and the students’ programming ability, as measured by a previous academic assessment. As not all subjects completed the measured task within the given time, we needed to use Kaplan-Meier survival curves and the Cox Proportional Hazard Model to analyse our data. Detailed inspection of the code produced during the experiment revealed some interesting qualitative results. Conclusions: We were unable to show a significant difference between the value of enhancing or documenting code as a way of gaining knowledge about unfamiliar programs. In the context of software maintenance this means that there is no advantage in spending unproductive time documenting code to gain knowledge.

In the presence of undocumented and unfamiliar hardware, the process of program comprehension becomes more complex. To perform maintenance activities, programmers must understand the functioning of each element independently, as well as their interactions. In this paper we examine the process taken by the first author during the analysis, porting and re-implementation of a software system that has a heavy reliance on undocumented customized hardware interfaces. This process also demonstrates the use of a twophase approach when migrating a mission-critical software system. The software was first ported to a new platform running a semi-compatible BASIC interpreter (phase 1) before a complete re-implementation was performed (phase 2). The experiences, strategies used, and lessons learned during the process are reported here. 1

Despite common belief, software engineers do not spend most time writing code. It has been shown that an approximate 50–90 % of development time is spent on code orientation, that is navigation and understanding of source code. This may include reading of local source code and documentation, searching the internet for code examples and tutorials, but also seeking help of other developers. In this dissertation we argue that, in order to support software engineers in code navigation and understanding, we need development tools that provide first-class support for the code orientation clues that developers rely on. We argue further that development tools need to tap unconventional information found in the source code in order to provide developers with code orientation clues that would be out of their reach without tool support. In a qualitative user study we identify four fundamental categories of orientation clues that developers use for code navigation and code understanding: lexical clues referring to identifier names and concepts, social clues referring to a developer’s personal network and to internet communities, episodic clues referring