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 developers 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, problems, 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 exploring code. 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.

To help developers more easily understand and explore code, I designed Reacher. 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.

282 pages

Return to: SCS Technical Report Collection
School of Computer Science

This page maintained by [email protected]