Previous research has documented the fragmented nature of software development work, with frequent interruptions and coordination. To explain this in more detail, we analyzed software developers ’ day-to-day information needs. We observed seventeen developers at a large software development company and transcribed their activities minute by minute in 90 minute sessions. We analyzed these logs for the information that developers sought, the sources that they used, and the situations that prevented information from being acquired. We identify twentyone information types and catalog the outcome and source when each type of information was sought. The most frequently sought information included awareness about artifacts and coworkers. The most often deferred searches included knowledge about design and program behavior, such as why code was written a particular way, what a program was supposed to do, and the cause of a program state. Developers often had to defer tasks because the only sources of knowledge were unavailable coworkers. 1.

Despite significant existing empirical work, little is known about the specific kinds of questions programmers ask when evolving a code base. Understanding precisely what information a programmer needs about the code base as they work is key to determining how to better support the activity of programming. The goal of this research is to provide an empirical foundation for tool design based on an exploration of what programmers need to understand about a code base and of how they use tools to discover that information. To this end, we undertook 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 mediumsized code base. The other study involved industrial programmers working on their own change tasks to 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 how they go about discovering that information. Based on a systematic analysis of the data from these user studies as well as an analysis of the support that current programming tools provide for these activities, this research makes four key contributions: (1) a catalog of 44 types of questions programmers ask, (2) a categorization of those questions into four categories based on the kind and scope of information needed to answer a question, (3) a description of important context for the process of answering questions, and (4) a description of support that is missing from current programming tools.

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.

Today’s integrated development environments (IDEs) are hampered by their dependence on files and file-based editing. We propose a novel user interface that is based on collections of lightweight editable fragments, called bubbles, which when grouped together form concurrently visible working sets. In this paper we describe the design of a prototype IDE user interface for Java based on working sets. A quantitative evaluation shows that developers could expect to view a sizeable number of functions concurrently with relatively few UI operations. A qualitative user evaluation with 23 professional developers indicates a high level of excitement, interest, and potential benefits and uses.

A reachability question is a search across feasible paths through a program for target statements matching search criteria. In three separate studies, we found that reachability questions are common and often time consuming to answer. In the first study, we observed 13 developers in the lab and found that half of the bugs developers inserted were associated with reachability questions. In the second study, 460 professional software developers reported asking questions that may be answered using reachability questions more than 9 times a day, and 82 % rated one or more as at least somewhat hard to answer. In the third study, we observed 17 developers in the field and found that 9 of the 10 longest activities were associated with reachability questions. These findings suggest that answering reachability questions is an important source of difficulty understanding large, complex codebases.

For many software projects, bug tracking systems play a central role in supporting collaboration between the developers and the users of the software. To better understand this collaboration and how tool support can be improved, we have quantitatively and qualitatively analysed the questions asked in a sample of 600 bug reports from the MOZILLA and ECLIPSE projects. We categorised the questions and analysed response rates and times by category and project. Our results show that the role of users goes beyond simply reporting bugs: their active and ongoing participation is important for making progress on the bugs they report. Based on the results, we suggest four ways in which bug tracking systems can be improved.

Recent research has shown that developers spend significant amounts of time navigating around code. Much of this time is spent on redundant navigations to code that the developer previously found. This is necessary today because existing development environments do not enable users to easily collect relevant information, such as web pages, textual notes, and code fragments. JASPER is a new system that allows users to collect relevant artifacts into a working set for easy reference. These artifacts are visible in a single view that represents the user's current task and allows users to easily make each artifact visible within its context. We predict that JASPER will significantly reduce time spent on redundant navigations. In addition, JASPER will facilitate multitasking, interruption management, and sharing task information with other developers.

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.

Source code search is an important activity for programmers working on a change task to a software system. We are at the early stages of a research program that is aiming to answer three research questions: (1) How effectively can programmers express (using today’s tools) the information they are seeking? (2) How effectively can programmers determine which of the matches returned from their searches are relevant to their task? and (3) In what ways can tools be improved to support programmers in more effectively expressing their information needs and exploring the results of searches? To begin answering these questions we have conducted a study in which we gathered both qualitative and quantitative data about programmers ’ search activities. Our analysis of this data is still incomplete, however this paper presents several of our initial observations about how programmers interact with the results from their searches. 1.

Software maintenance tasks typically involve an important amount of program investigation effort on the part of software developers. To what extent can we benefit from prior program investigation activities to decrease this effort? To investigate this question, we studied the revision history of two systems to determine how knowledge derived from prior investigation activities could have been reused to support other change tasks. Our initial investigation used a tool, ConcernDetector, that can recommend sets of program elements associated with a high-level concern when elements in the set overlap with elements currently being modified. We discovered that simple overlap-based techniques for retrieving prior investigation knowledge have important limitations, and that effective reuse of prior program investigation knowledge requires analyses that can partially infer the nature and intent of a task. 1.