Jan-Peter Krämer

Stacksplorer: call graph navigation helps increasing code maintenance efficiency

We present Stacksplorer, a new tool to support source code navigation and comprehension. Stacksplorer computes the call graph of a given piece of code, visualizes relevant parts of it, and allows developers to interactively traverse it. This augments the traditional code editor by offering an additional layer of navigation. Stacksplorer is particularly useful to understand and edit unknown source code because branches of the call graph can be explored and backtracked easily. Visualizing the callers of a method reduces the risk of introducing unintended side effects. In a quantitative study, programmers using Stacksplorer performed three of four software maintenance tasks significantly faster and with higher success rates, and Stacksplorer received a System Usability Scale rating of 85.4 from participants.

How tools in IDEs shape developers' navigation behavior

Understanding source code is crucial for successful software maintenance, and navigating the call graph is especially helpful to understand source code [12]. We compared maintenance performance across four different development environments: an IDE without any call graph exploration tool, a Call Hierarchy tool as found in Eclipse, and the tools Stacksplorer [7]and Blaze [11]. Using any of the call graph exploration tools more developers could solve certain maintenance tasks correctly. Only Stacksplorer and Blaze, however, were also able to decrease task completion times, although the Call Hierarchy offers access to a larger part of the call graph. To investigate if this result was caused by a change in navigation behavior between the tools, we used a set of predictive models to create formally comparable descriptions of programmer navigation. The results suggest that the decrease in task completion times has been caused by Stacksplorer and Blaze promoting call graph navigation more than the Call Hierarchy tool.

Blaze: supporting two-phased call graph navigation in source code

Understanding source code is crucial for successful software maintenance. A particularly important activity to understand source code is navigating the call graph [4]. Programmers have developed distinct strategies for effective call graph exploration [3, 9]. We introduce Blaze, a source code exploration tool tailored closely to these strategies. In a study, we compare Blaze to Stacksplorer [2], a tool that visualizes the immediate neighborhood of the current method in the call graph, to a tool resembling the standard Call Hierarchy view in the Eclipse IDE, and to an unmodified Xcode installation. The call graph exploration tools significantly increased success rates in typical software maintenance tasks, and using Stacksplorer or Blaze significantly reduced task completion times compared to using the Call Hierarchy or Xcode.

How live coding affects developers' coding behavior

We report on the behavior of developers working with a live coding environment, which provides information about a programs execution immediately after each change to the source code. The live coding environment we used shows information about each individual source code line, e.g., changed variable values or truth values of conditions. In comparison to developers working in a non-live environment, those working live found and fixed bugs they introduced significantly faster. Further, working live encouraged developers to switch between editing and debugging phases more frequently.

Using Runtime Traces to Improve Documentation and Unit Test Authoring for Dynamic Languages

Documentation and unit tests increase software maintainability, but real world software projects rarely have adequate coverage. We hypothesize that, in part, this is because existing authoring tools require developers to adjust their workflows significantly. To study whether improved interaction design could affect unit testing and documentation practice, we created an authoring support tool called Vesta. The main insight guiding Vestas interaction design is that developers frequently manually test the software they are building. We propose leveraging runtime information from these manual executions. Because developers naturally exercise the part of the code on which they are currently working, this information will be highly relevant to appropriate documentation and testing tasks. In a complex coding task, nearly all documentation created using Vesta was accurate, compared to only 60% of documentation created without Vesta, and Vesta was able to generate significant portions of all tests, even those written manually by developers without Vesta.

Stacksplorer: understanding dynamic program behavior

To thoroughly comprehend application behavior, programmers need to understand the interactions of objects at runtime. Today, these interactions are often poorly visualized in common IDEs except during debugging. Stacksplorer allows visualizing and traversing potential call stacks in an application even when it is not running by showing callers and called methods in two columns next to the code editor. The relevant information is gathered from the source code automatically.

Interacting with code : observations, models, and tools for usable software development environments

xv

An empirical study of programming paradigms for animation

Animations are an essential part of many modern user interfaces. They are often defined programmatically, which allows for parametrization and reuse. Two programming paradigms to define animations are common: Procedural animation programming allows the developer to make explicit updates to object properties at each frame, allowing maximum control over behavior. Declarative animation programming allows the developer to specify keyframes, i.e., the value of an object’s property at a given point in time. All frames between two keyframes are automatically interpolated by the animation library. In this paper, we investigate how these common programming paradigms differ in terms of developers’ productivity. In a controlled laboratory study, we asked developers to implement a set of simple animations using both paradigms. We found that developers can implement a given behavior faster using declarative animation programming, but the abstraction introduced by automatically creating the animation through keyframe interpolation left participants with unexpected behavior for some tasks.