Edit-Run Behavior in Programming and Debugging

TL;DR

This study analyzes the frequency, duration, and characteristics of edit-run cycles in programming and debugging, revealing their commonality and suggesting improvements for developer tools.

Contribution

It provides the first detailed empirical analysis of edit-run cycles, highlighting their patterns and proposing design recommendations for better tooling support.

Findings

Developers perform an average of 7 edits before fixing a defect.

Cycle length is longer during programming (3 min) than debugging (1 min).

Activities beyond edit and run extend cycle duration to 5 minutes.

Abstract

As developers program and debug, they continuously edit and run their code, a behavior known as edit-run cycles. While techniques such as live programming are intended to support this behavior, little is known about the characteristics of edit-run cycles themselves. To bridge this gap, we analyzed 28 hours of programming and debugging work from 11 professional developers which encompassed over three thousand development activities. We mapped activities to edit or run steps, constructing 581 debugging and 207 programming edit-run cycles. We found that edit-run cycles are frequent. Developers edit and run the program, on average, 7 times before fixing a defect and twice before introducing a defect. Developers waited longer before again running the program when programming than debugging, with a mean cycle length of 3 minutes for programming and 1 minute for debugging. Most cycles involved an edit to a single file after which a developer ran the program to observe the impact on the final output. Edit-run cycles which included activities beyond edit and run, such as navigating between files, consulting resources, or interacting with other IDE features, were much longer, with a mean length of 5 minutes, rather than 1.5 minutes. We conclude with a discussion of design recommendations for tools to enable more fluidity in edit-run cycles.