©2004 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

Much of software developers’ time is spent understanding unfamiliar code. To better understand how developers gain this understanding and how software development environments might be involved, a study was performed in which developers were given an unfamiliar program and asked to work on two debugging tasks and three enhancement tasks for 70 minutes. The study found that developers interleaved three activities. They began by searching for relevant code both manually and using search tools; however, they based their searches on limited and misrepresentative cues in the code, environment, and executing program, often leading to failed searches. When developers found relevant code, they followed its incoming and outgoing dependencies, often returning to it and navigating its other dependencies; while doing so, however, Eclipse’s navigational tools caused significant overhead. Developers collected code and other information that they believed would be necessary to edit, duplicate, or otherwise refer to later by encoding it in the interactive state of Eclipse’s package explorer, file tabs, and scroll bars. However, developers lost track of relevant code as these interfaces were used for other tasks, and developers were forced to find it again. These issues caused developers to spend, on average, 35 percent of their time performing the mechanics of navigation within and between source files. These observations suggest a new model of program understanding grounded in theories of information foraging and suggest ideas for tools that help developers seek, relate, and collect information in a more effective and explicit manner.

Little is known about how developers think about design during code modification tasks or how experienced developers ’ design knowledge helps them work more effectively. We performed a lab study in which thirteen developers worked for 3 hours understanding the design of a 54 KLOC open source application. Participants had from 0 to 10.5 years of industry experience and were grouped into three “experts ” and ten “novices. ” We observed that participants spent their time seeking, learning, critiquing, explaining, proposing, and implementing facts about the code such as “getFold-Level has effects”. These facts served numerous roles, such as suggesting changes, constraining changes, and predicting the amount of additional investigation necessary to make a change. Differences between experts and novices included that the experts explained the root cause of the design problem and made changes to address it, while novice changes addressed only the symptoms. Experts did not read more methods but also did not visit some methods novices wasted time understanding. Experts talked about code in terms of abstractions such as “caching ” while novices more often described code statement by statement. Experts were able to implement a change faster than novices. Experts perceived problems novices did not and were able to explain facts novices could not. These findings have interesting implications for future tools.

being asked to maintain large, multi-threaded software systems; however, the maintenance of such systems is typically not wellcovered by software engineering texts or curricula. We conducted a think-aloud study with 15 students in a graduate-level computer science class to discover the strategies that students apply, and to what effect, in performing corrective maintenance on concurrent software. We collected think-aloud and action protocols, and annotated the protocols for a number of behavioral attributes and maintenance strategies. We divided the protocols into groups based on the success of the participant in both diagnosing and correcting the failure. We evaluated these groups for statistically significant differences in these attributes and strategies. In this paper, we report a number of interesting observations that came from this study. All participants performed diagnostic executions of the program to aid program comprehension; however, the participants that used this as their predominant strategy for diagnosing the fault were all unsuccessful. Among the participants that successfully diagnosed the fault and displayed high confidence in their diagnosis, we found two commonalities. They all recognized that the fault involved the violation of a concurrent-programming idiom. And, they all constructed detailed behavioral models (similar to UML sequence diagrams) of execution scenarios. We present detailed analyses to explain the attributes that correlated with success or lack of success. Based on these analyses, we make recommendations for improving software engineering curriculums by better training students how to apply these strategies effectively.

Previous research in computer science shows that developers spend a large fraction of their time navigating through source code. Improving developers ’ effectiveness in navigating code thus should yield significant productivity improvements. Previous research in a number of fields suggests that a more breadth-first approach to problem solving should be more successful than a more depth-first approach. Unfortunately, modern Integrated Development Environments (IDEs) do not support a breadth-first search well because they do not help developers keep track of exploration paths well. We implemented an IDE that allows developers to track different exploration paths more easily, and ran a user study with seven subjects. To our surprise, subjects used the tool to mark waypoints instead of to facilitate a more breadth-first search. Intrigued, we examined more closely techniques for finding a starting point and for tracing relationships from there. We describe our findings, including common difficulties our subjects encountered, and propose a novel tool to reduce incorrect search paths.

Many small and medium-sized systems have little or no design documentation, which makes program understanding during maintenance enormously more difficult when performed by outsiders. Thus, if only minimal design documentation is available, which form should it take to maximize its usefulness? We suggest that it is helpful if the documentation describes a tour through the source code, leading the user directly to relevant details. This work reports an evaluation of this conceptual idea in the form of a controlled experiment with 59 student subjects working on a difficult program understanding task in the context of the 27 KLOC JHotDraw graphics framework. One group received a plain text documentation, the other received tourstructured documentation which they navigated by using an Eclipse plugin called JTourBus that we constructed for the experiment. The results indicate that program understanding can be achieved somewhat faster (albeit not more correctly) with JTourBus than with a plain text document.

In recent years, the software engineering community has begun to study program navigation and tools to support it. Some of these navigation tools are very useful, but they lack a theoretical basis that could reduce the need for ad hoc tool building approaches by explaining what is fundamentally necessary in such tools. In this paper, we present PFIS (Programmer Flow by Information Scent), a model and algorithm of programmer navigation during software maintenance. We also describe an experimental study of expert programmers debugging real bugs described in real bug reports for a real Java application. We found that PFIS’ performance was close to aggregated human decisions as to where to navigate, and was significantly better than individual programmers ’ decisions. Author Keywords Information foraging, debugging, software maintenance

The communities of Generative Programming (GP) and Program Comprehension (PC) look at similar problems: GP derives a program from a specification, PC derives a specification from a program. A basic difference between the two is GP's use of specific knowledge representations and mental models that are essential for program synthesis. In this paper, I present a historical review of the Grand Challenges, results, and outlook for GP as they pertain to PC.

First and foremost I would like to thank my advisor, Alex Kirlik. As this project has traveled through numerous literatures and tried to find a balance between cognitive psychology and software engineering, he has really helped to get to the bottom of what matters and is important. He has always had something useful to provide despite not having a background in software engineering or the psychology of programming, and his perspectives have shaped this project. I would like to thank Ralph Johnson for providing advice and suggestions and for inspiring me to be interested in software design and the topic of this thesis. I would like to thank my roommates for helping me practice presentations, proof materials, figure out statistics, and whatever else I needed help with at a moments notice. I would like to thank my all of my friends who were willing to be participants, especially the two willing to be unpaid pilot participants. I would like to thank Susan Garnsey for teaching me what a research life is like and for always having something kind, understanding, and constructive to say no matter what the situation. I would like to Colleen Conley for having a handout for every question and all of the psych honors students for being good comrades. And finally I would like to thank my parents for always being supportive of everything I do.

Motivation. Software maintenance is a significant part of the software life-cycle cost. Current research focuses on the maintenance of application software. Despite increased focus on systems integration, there is limited research on maintaining integrated systems. Before progressing with informing software integration practice, researchers therefore need to better understand the actual work of maintaining integrated systems. Research. To this end, a study of maintaining an integrated system in practice has been conducted. The study is conducted in the context of a community of volunteer software integrators. The research combines field studies with document analysis, asking: RQ1: How is knowledge of software failures developed during geographically distributed software maintenance? RQ2: How do software developers build knowledge of how to replace a businesscritical software system? RQ3: What are the characteristics of large-scale software maintenance work in a geographically distributed community of volunteers? Contributions. The main empirical contribution offered by this thesis is insight into the social