Arty Starr
March 24, 2026 · 7 min read
Giving Developers Words to Explain What's Happening When Software Gets Out of Control
I still remember the first time I tried to explain the "technical debt" metaphor to a group of business managers at a workshop event. They knew very little about software development, but a great deal about operating a business. I shared the classic story—of problems building up over time, the rush to deliver features, and the shortcuts we take being like credit card debt, with interest payments accumulating and making it really expensive to change the software.
Their reaction? "Oh, that doesn't sound so bad."
"What?! You mean, you don't want to know about the interest rate… or anything?" I asked.
I didn't understand why the business managers weren’t more alarmed. They should be in a panic with fire coming out of their ears or something. I learned something very important that day: why the severity of what developers are trying to communicate doesn’t seem to land.
Here's what I learned from the savvy business folk:
Loans in the business world are a predictable financial leverage tool. As a business manager, I can take out a loan to help me operate my business, and if there's a predictable increase in costs over time, I can manage that. Business math starts with something like, "increase profits by 10%". From there, we work backwards to decide what buckets to invest the money in (sales, engineering, marketing, etc.). Facing this "technical debt" situation, I might increase investment in sales as a strategy to offset the rising development costs. As long as the business system remains predictable (as we suggested it would be with our tech debt metaphor) operating the business is not difficult, and technical debt doesn't sound particularly scary.
But it should sound scary—if what developers were trying to communicate was getting through.
There's a reason developers get so concerned about the severity of the problems, and the pains that come with them not being addressed. The phenomenology of what's actually happening is more like wheels falling off the bus… project going off the rails… things spinning out of control. The challenge developers are experiencing isn't shaped like a predictable increase in costs over time, it's a loss of predictability, a loss of sustainability, and a loss of control. It's an increase in confusion, frustration, stress, and cognitive fatigue. But the lack of visibility—and the difficulty explaining the problems—makes it hard to communicate the severity of the situation, and often prevents the investment of time and resources that could make the situation better.
In 2022, at the first DPE Summit (Developer Productivity Engineering) opening keynote, Hans Dockter—founder of Gradle—was discussing this same communication breakdown between developers and managers. He described how developers have a strong intuitive sense of when their tools, systems, or processes are creating drag, but struggle to explain their “gut feel” to managers who do not share the lived experience of writing code. Dockter proposed that cognitive fatigue is a key concept from cognitive science that could help bridge this gap—offering a way to make the developer’s experience more understandable to others. He argued that the software industry urgently needs better conceptual foundations grounded in cognitive science—frameworks that could explain the developer’s experience in a way that does not require having lived it firsthand.
This seed of an idea directly shaped the direction of our recent grounded theory study at University of Victoria, where we set out to better understand the developer’s cognitive experience of troubleshooting and to develop a theory rooted in cognitive science that could give developers the words to explain what’s happening. Troubleshooting is a particularly intense and draining aspect of software work, placing sustained demands on attention, working memory, and mental modeling. By surfacing and naming the confusion experience inherent in troubleshooting in terms of neurological and attentional dynamics, our theory explains how prolonged troubleshooting can deplete cognitive resources and lead to cognitive fatigue. This reframes the mental strain developers are experiencing as a capacity constraint, rather than simply an emotion.
Here's what a typical developer's experience feels like after encountering an unexpected behavior—what we call a "puzzling event". It gets increasingly more frustrating the longer a developer spends confused and unable to resolve the problem:
P10 from our study, described the feeling and discomfort of realizing your mental model is wrong:
“It was basically that nagging feeling. I realized I felt that my mental model was the thing that was wrong
somehow, but the reason it was wrong was elusive because I was fairly confident that my mental model was
true. So that was just a very frustrating feeling.”
One of the most overlooked hidden costs and long-term risks on software projects is the rising cognitive cost of troubleshooting. As software systems evolve, they often grow in complexity—accumulating dependencies, behaviors, and design decisions that can become harder to reason about over time. Maintaining a system requires that developers can make sense of unexpected behavior when it occurs. As troubleshooting becomes more difficult, developers spend more time confused and unable to make sense of the system. Over time, this rising troubleshooting effort can become a leading indicator of risk—signaling when the team’s ability to sustain understanding is beginning to erode.
Our theory summarizes this idea with a simple 2x2 framework illustrating the relationship between the likelihood of unexpected behavior (puzzling events) and the cognitive effort required to troubleshoot, highlighting how compounding difficulties can lead to cognitive fatigue:
Our theory reframes how we understand long-term project risks in software development:
Troubleshooting time becomes a leading indicator of sustainability risk and loss of control in software systems—because it reflects the developer’s ability to sustain understanding amid increasing complexity.
Where the technical debt metaphor invites teams to locate problems in specific pieces of code, our theory suggests a broader, experience-oriented perspective: what matters is not just the state of the code, but how hard it is for developers to make sense of what the system is doing.
This is the core of the communication gap.
The severity that developers are trying to describe comes from a loss of understanding—and the difficulty of restoring that understanding once they are confused. For managers who may not have direct experience writing code, the experience of confusion creates a shared reference point. Both developers and managers can likely relate to what it feels like to be confused and stuck for hours, and how frustrating and cognitively fatiguing that experience can be. As the software becomes increasingly complex, we can imagine encountering more circumstances of puzzling events and confusion, and it becoming increasingly difficult to troubleshoot.
With a shared understanding that is closer to the phenomena being encountered and grounded in lived experience, developers and managers can finally get on the same page.
