Active code completion allows library developers to introduce interactive and highly-specialized code generation interfaces, called palettes, directly into the editor as code completion menus. Using several empirical methods, we examine the contexts in which such a system could be useful, describe the design constraints governing the system architecture as well as particular code completion interfaces, and design one such system, named Graphite. ICSE 2012

REACHER lets developers search along call graphs and find matching statements. An interactive call graph encodes causality, ordering, type membership, repetition and choice and helps developers to remain oriented while navigating through code. REACHER uses a novel fast feasible path analysis to eliminate some of the most common types of infeasible paths. In a controlled experiment, developers with REACHER were 5.6 times more successful answering reachability questions in significantly less time and reported that REACHER helped them to think more visually. VL/HCC 2011

Static analyses simulate the behavior of a program across all possible executions, but over-approximate the set of exeuctions they consider by following infeasible paths that never execute. Existing approaches to eliminating infeasible paths are designed to precisely determine if an error path may execute, but to do so, use models of execution constraints that take hours to analyze for even small programs. We designed an analysis suitable for use in interactive tools that quickly eliminates the most common infeasible paths. We found that these are caused by constant controlled conditionals, conditionals to which constants are propagated along alternative paths through which the conditional is reached. Common examples include flags, case selects on enums, dynamic dispatch, and messages sent over buses. Our analysis partially path-sensitively propagates constants across demand-driven interprocedural paths, using precomputed summaries of intraproceudral paths through methods. In less than a second of analysis time, it is able to eliminate many common infeasible paths.

Developers reported asking 94 hard-to-answer questions about code, spanning 24 software engineering topics. Some of these questions are addressed by existing research tools, suggesting that if these tools help and are commercially developed, such tools would solve important problems developers face. Other questions revealed situations in which, despite trying to solve the problem, existing research tools just aren't applicable. For example, research in clone detectors has tried to detect functionality or code that could be refactored. But clone detectors do not help in several of the situations developers reported - e.g., detecting redundant data between equally accessible structures. Other questions reveal entirely new areas for tools – e.g., why wasn’t it done this other way, or what is the policy for doing this? PLATEAU 2010

A reachability question is a search along paths through code. Developers ask reachability questions when reasoning about causality, ordering, type membership, repetition, 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 paths through the call graph lead to what they’re looking for and which paths are feasible and execute. These challenges cause bugs and waste time. In one study, half of the inserted bugs were caused by challenges answering reachability questions; other developers simply gave up. In observations of professional developers at work, nine of the ten longest debugging and investigation activities involved answering a single reachability question, each requiring tens of minutes of developers’ time. ICSE 2010

Developers ask questions about object structure when mapping functionality to packages, determining where to put functionality or how to access an object, and understanding the cardinality of relationships. Some of these questions are specifically about object structure rather than class structure – for example, which instances handle an event – demonstrating that depicting object structure is important. Observing developers use our object visualization tool, we found that such tools need flexibility to be able to easily organize objects into the abstractions that make sense for them. CHASE 2010, SHARK 2010

By decomposing activities into sets of strategies and designing studies to understand these strategies rather than only measure task time or bugs, our understanding of coding activities will be improved and our evaluations will be more informative. Realizing this goal requires better understanding the strategies that exist, the factors that influence which strategies developers choose, and the effectiveness of these strategies. CHASE 2010

As developers reason about code, they see code not as a list of statements but as a network of design decisions. Developers seek, learn, critique, explain, propose, and implement design decisions. Information about design decisions helps to suggest changes, constrain changes, and predict how much more investigation is necessary to make a planned change. Lacking the ability to see higher-level decisions and the dependencies between these decisions, developers with less professional experience were unable to propose the better solutions of the more experienced developers. FSE 2007

No activity dominates developers’ time – developers report spending nearly equal time understanding, discussing, writing, and editing code. Developers report that their most serious problems are: (1) understanding the rationale behind design decisions and (2) interruptions from their teammates. We also gathered a bunch of data on which tools developers use for various activities. Developers report that code duplication is a serious problem: frequent and prob- lematic causes of code duplication are not addressed by existing research – multiple developers implementing similar functionality, copying entire codebases, and maintaining old versions. ICSE 2006

Proponents of object-oriented design argue that OO designs better match developers' mental model of the domain, supporting easier use of domain knowledge when working with such code. To test this claim, we conducted an experiment in which developers edited either an OO or procedural implementation with or without the knowledge that it was implementing a bowling scoring algorithm. Surprisingly, developers working with a procedural implementation benefitted from domain knowledge while those with an OO implementation did not. Undergrad thesis

Flow - a state of complete immersement in the task at hand - is believed to be the happiest moments people experience. To test this claim, we interrupted people at work and asked them to report what they were doing and how they felt. Surprisingly, the activities in which people were the happiest were not those in which they were the most engaged. And people were more likely to be in flow for easy activities than optimally challenging activities, again contradicting existing theory. People are most engaged in the activities for which they are intinscially motiviated, inspire their curiosity, and feel are important. Motivation class paper