For the Monday, June 1 #PapersInSystems discussion, we will visit some of the systems-supporting practices that folk in our community have used or developed to support the socio-technical systems work we do. We will discuss:

- Container Differences Exchanges Model, which @donaldegray has used with organizations and Don will lead the discussion

- Decision KP Maps, created by @roundcrisis and discussion will be led by Andrea

Info/Enroll: https://ti.to/bredemeyer/scaffoldingconversations

The reading to support the discussion is at:

- Container Differences Exchanges Model (pdf): https://www.hsdglobalservices.org/assets/documents/5.1.1.3.cde-30apr16.pdf

- Decision KP Maps: https://www.roundcrisis.com/2026/02/04/making-of-a-decision-5/

And participants will have an opportunity to share other canvases/models/maps/etc. that we find useful in supporting socio-technical teams and system design.

#PapersInSystems, June 1 (Monday), 2pm Eastern: Scaffolding Conversations (see upthread) with @donaldegray and @roundcrisis

PapersInSystems, July 8 (yes, Wednesday), 1pm Eastern:
“Theory of Troubleshooting” by Arty Starr and Margaret-Anne Storey, and discussion will be led by @art3starr (Arty Starr)

https://ti.to/bredemeyer/theory-of-troubleshooting

Papers in Systems Discussion: Theory of Troubleshooting

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."

Tito

@RuthMalan @donaldegray @roundcrisis

So excited for this! Will be so much fun to chat with everyone after reading our paper. 😁

@art3starr @RuthMalan @donaldegray @roundcrisis Hi Arty... I just read your paper, I'm very impressed.

As a (now-retired) software dev who did a lot of troubleshooting / debugging in my career, and tried to think carefully about the process, I found the model you ended up with mapped quite closely to my own experiences and my own (much less well thought-out) approach to explaining troubleshooting to others.

@DaleHagglund @RuthMalan @donaldegray @roundcrisis

Yay that's so awesome to hear Dale! 💜