We explore the concept of static-dynamic coupling--the degree to which changes in a program's static modular structure imply changes to its dynamic structure. This paper investigates the impact of static-dynamic coupling in a programming language on the effort required to evolve the coarse modular structure of programs written in that language. We performed a series of remodularization case studies in both Java and SubjectJ. SubjectJ is designed to be similar to Java, but have strictly less static-dynamic coupling. Our results include quantitative measures-time taken and number of bugs introduced--as well as a more subjective qualitative analysis of the remodularization process. All results point in the same direction and suggest that static-dynamic coupling causes substantial accidental complexity for the remodularization of Java programs.

Little is known about the specific kinds of questions programmers ask when evolving a code base and how well existing tools support those questions. To better support the activity of programming, answers are needed to three broad research questions: 1) What does a programmer need to know about a code base when evolving a software system? 2) How does a programmer go about finding that information? 3) How well do existing tools support programmers in answering those questions? We undertook two qualitative studies of programmers performing change tasks to provide answers to these questions. In this paper, we report on an analysis of the data from these two user studies. This paper makes three key contributions. The first contribution is a catalog of 44 types of questions programmers ask during software evolution tasks. The second contribution is a description of the observed behavior around answering those questions. The third contribution is a description of how existing deployed and proposed tools do, and do not, support answering programmers' questions.

Though many tools are available to help programmers working on change tasks, and several studies have been conducted to understand how programmers comprehend systems, little is known about the specific kinds of questions programmers ask when evolving a code base. To fill this gap we conducted two qualitative studies of programmers performing change tasks to medium to large sized programs. One study involved newcomers working on assigned change tasks to a medium-sized code base. The other study involved industrial programmers working on their own change tasks on code with which they had experience. The focus of our analysis has been on what information a programmer needs to know about a code base while performing a change task and also on howthey go about discovering that information. Based on this analysis we catalog and categorize 44 different kinds of questions asked by our participants. We also describe important context for how those questions were answered by our participants, including their use of tools.

This paper introduces an automated technique for feature location: helping developers map features to relevant source code. Like several other automated feature location techniques, ours is based on execution-trace analysis. We hypothesize that these techniques, which rely on making binary judgments about a code element's relevance to a feature, are overly sensitive to the quality of the input. The main contribution of this paper is to provide a more robust alternative, whose most distinguishing characteristic is that it employs ranking heuristics to determine a code element's relevance to a feature. We believe that our technique is less sensitive with respect to the quality of the input and we claim that it is more effective when used by developers unfamiliar with the target system. We validate our claim by applying our technique to three systems with comprehensive test suites. A developer unfamiliar with the target system spent a limited amount of effort preparing the test suite for analysis. Our results show that under these circumstances our ranking-based technique compares favorably to a technique based on binary judgements.