To build new tools and programming languages that make it easier for professional software developers to create, debug, and understand code, it is helpful to better understand the questions that developers ask during coding activities. We surveyed professional software developers and asked them to list hard-to-answer questions that they had recently asked about code. 179 respondents reported 371 questions. We then clustered these questions into 21 categories and 94 distinct questions. The most frequently reported categories dealt with intent and rationale – what does this code do, what is it intended to do, and why was it done this way? Many questions described very specific situations – e.g., what does the code do when an error occurs, how to refactor without breaking callers, or the implications of a specific change on security. These questions revealed opportunities for both existing research tools to help developers and for developing new languages and tools that make answering these questions easier.

During Software Product Line (SPL) maintenance tasks, Virtual Separation of Concerns (VSoC) allows the programmer to focus on one feature and hide the others. However, since features depend on each other through variables and control-flow, feature modularization is compromised since the maintenance of one feature may break another. In this context, emergent interfaces can capture dependencies between the feature we are maintaining and the others, making developers aware of dependencies. To better understand the impact of feature dependencies during SPL maintenance, we have investigated the following two questions: how often methods with preprocessor directives contain feature dependencies? How feature dependencies impact maintenance effort when using VSoC and emergent interfaces? Answering the former is important for assessing how often we may face feature dependency problems. Answering the latter is important to better understand to what extent emergent interfaces complement VSoC during maintenance tasks. To answer them, we analyze 43 SPLs of different domains, size, and languages. The data we collect from them complement previous work on preprocessor usage.

Observations of developers indicate that developers try to answer a variety of questions by searching across control flow paths through a program for statements matching search criteria. We believe that tools that better support this activity can help developers answer these questions more easily, quickly, and accurately.

Software developers understanding and exploring code spend much of their time asking questions and searching for answers. Yet little has been known about the questions devel-‐ opers ask, the strategies used to answer them, and the challenges developers face. Through interviews, surveys, and observations, a series of 7 studies were conducted that begin to address this gap, contributing a better understanding of developers ’ tools, practices, prob-‐ lems, questions, and strategies, and a model of how developers reconstruct design decisions from code. A design process is described for using studies of developers ’ work to design more useful tools for developers. These studies reveal that reachability questions are a central part of understanding and ex-‐ ploring code. A reachability question is a search along paths through code. Developers ask reachability questions when reasoning about causality, ordering, type membership, repeti-‐ tion, and choice. For example, to debug a deadlock, a developer searched downstream for calls acquiring resources to reconstruct how and why resources were acquired. Existing tools make these questions challenging to answer by forcing developers to guess which

What do developers do during coding activities, and how can tools more effectively support these activities? What questions are hard to answer, why does investigating and debugging code take so long, and why do bugs occur? The goal of my research is to identify the most important problems developers face using human-computer interaction techniques and use software engineering techniques to design solutions. I study developers through observations, surveys, and interviews to understand how they reason about software, and I then build models of their activities, questions, and strategies. From these models, I identify opportunities for novel tools to make a large impact. I then design and evaluate tools exploiting these opportunities to prevent bugs and make developers more productive. What makes coding activities challenging? In a series of studies, I investigated the nature of developer activity during coding activities and identified challenges that can make these activities time-consuming or error-prone. How do developers work? I first surveyed and interviewed developers about their work [6]. No single activity dominates developers ’ time – developers report spending nearly equal time understanding, discussing, writing, and editing code. Developers report that their most serious problems

Understanding the strategies that developers use during coding activities is an important way to identify challenges developers face and the corresponding opportunities for tools, languages, or processes to better address the challenges and more effectively support the strategies. After creating a design, evaluation studies often measure task success, time, and bugs to argue that the design improves programmer productivity. Considering the strategies that developers use while conducting these studies increases the likelihood of a successful test and makes the results easier to generalize. Therefore, we believe that identifying strategies developers use is an important goal. Beyond identifying strategies, there are also research opportunities in better understanding how developers choose strategies.

Abstract—Developers navigate and reason about call graphs throughout investigation and debugging activities. This is often difficult: developers can spend tens of minutes answering a single question, get lost and disoriented, and erroneously make assumptions, causing bugs. To address these problems, we designed a new form of interactive call graph visualization – REACHER. Instead of leaving developers to manually traverse the call graph, REACHER lets developers search along control flow. The interactive call graph visualization encodes a number of properties that help developers answer questions about causality, ordering, type membership, repetition, choice, and other relationships. And developers remain oriented while navigating. To evaluate REACHER’S benefits, we conducted a lab study in which 12 participants answered control flow questions. Compared to an existing IDE, participants with REACHER were over 5 times more successful in significantly less time. All enthusiastically preferred REACHER, with many positive comments. Keywords-code exploration, call graphs, control flow, program visualization, program comprehension I.

To my family for their unlimited support.

Software evolves with continuous source-code changes. These code changes usually need to be understood by software engineers when performing their daily development and maintenance tasks. However, despite its high importance, such change-understanding practice has not been systematically studied. Such lack of empirical knowledge hinders attempts to evaluate this fundamental practice and improve the corresponding tool support. To address this issue, in this paper, we present a large-scale quantitative and qualitative study at Microsoft. The study investigates the role of understanding code changes during software-development process, explores engineers ’ information needs for understanding changes and their requirements for the corresponding tool support. The study results reinforce our beliefs that understanding code changes is an indispensable task performed by engineers in software-development process. A number of insufficiencies in the current practice also emerge from the study results. For example, it is difficult to acquire important information needs such as a change’s completeness, consistency, and especially the risk imposed by it on other software components. In addition, for understanding a composite change, it is valuable to decompose it into sub-changes that are aligned with individual development issues; however, currently such decomposition lacks tool support.