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 Vesta's 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.

We report on the behavior of developers working with a live coding environment, which provides information about a program's 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.

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.

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.