Theory of Troubleshooting

Next in our Papers in Systems discussion series: “Theory of Troubleshooting” by Arty Starr and Margaret-Anne Storey.

The discussion will be led by Arty Starr.

When: July 8, 2026, 1PM - 2PM Eastern Time (US/Canada) (19:00 CEST). The Zoom room will remain open until 2:30PM (ET) for informal discussion. (Check time in your timezone: WorldTimeBuddy )

The official link to the paper is: https://dl.acm.org/doi/10.1145/3800945 (and you are encouraged to download it from that ACM link, for academic credit reasons). If that is hard to read due to the watermark, you can also download it here: https://arxiv.org/abs/2602.10540

The importance of this paper is all the greater, as pressures increase, and more code is generated, and generated faster, and the need to communicate Developer Experience in ways that resonate, is of such great consequence.

Some quotes to tease the appetite:

"the Theory of Troubleshooting that followed from our analysis: the cognitive problem-solving process of identifying, understanding, and constructing a mental model of the cause of an unexpected system behavior."

"While cognitive fatigue has been widely studied in domains outside software development [1], research within this context remains limited. One exception is a survey by Sarkar and Parnin (n=311), which found that a majority of developers experience severe and frequent issues with cognitive fatigue [35]. Their findings highlight the need to better understand the cognitive demands placed on developers and how they contribute to fatigue. In software development, such demands are not evenly distributed across activities. Troubleshooting, in particular, places sustained demands on attention, working memory, and mental modeling, as developers work to reconcile unexpected system behavior with their existing understanding."

"What makes the developer’s process troubleshooting is not the presence of a bug, but rather the developer’s engagement in a cognitive process of trying to understand unexpected behavior. These are related, but oriented differently: one reflects a condition of the code, the other a shift in the developer’s cognitive activity"

"As developers strive to make sense of a confusing system behavior, they also draw on a “gut feel” intuition that guides their strategy, shaping where they look and how they begin. This intuitive sense—what we call experiential intuition—is a tacit form of knowing shaped by accumulated experience (expertise), in which perceived similarities to past situations provide a felt sense of direction, even before a clear rationale has formed."