Arty Starr
June 11, 2026 · 5 min read
Supporting the Moment: Seeing Software as
Activity Instead of Artifact
One of the things I keep coming back to, is why we need more words than "debt" to help us understand the real challenges we face in software development. As I've been pondering this new Triple Debt Model by Margaret-Anne Storey, and having lots of fun conversations with her as well (I'm fortunate to also have her as my PhD supervisor), I’ve been thinking quite a lot about this.
There is a way in which metaphors create a thinking scaffold that constrains the ways in which we can see. With a metaphor like “debt” that is a noun, we automatically focus on the objects and try to make sense of our world through the metaphor. We see the code. We see the humans. We see the externalized artifacts. The debt metaphor also carries with it patterns of “building up” with cumulative effects and “repayment plans” that reverse the problem, so we look for those patterns too. We see piles of "debt-like" things building up in our code, piles of understandings missing from our brains, and piles of externalized goals and rationale that should be written down somewhere, but aren't. The metaphor creates a nounification of our world as a way of seeing.
What we miss when we see through a lens made of nouns, are the processes, the verbs, what is happening over time, and more precisely, what is going wrong when the system is moving. Developers are continuously exploring, orienting, deciding, creating, validating, and responding to feedback. There's always a context, a goal, a problem to solve that the developer is moving and navigating from within. The challenges that arise in this context happen within a temporal unfolding of cognitive experience as the developer makes progress toward a goal. The challenge occurs within the activity. For example, a developer runs the code just generated by AI, encounters a weird behavior and has to figure out what’s wrong, but they don’t have a hunch about where the problem might be (experiential intuition), because they don’t understand the code like they would have by writing it directly [1]. This is the “cognitive debt” phenomena as it is experienced in motion within the context of the software activity.
The value of clean code, or understanding in the head, or having externalized artifacts that capture intent, is not intrinsic. The value comes from how well these affordances support the activity, and how well they help us reach our goals. The developer needs ways to address the challenges arising in the moments they are in. The “repayment plan” for cognitive debt is not about putting arbitrary piles of understandings in the developer’s head. Rather, we need a strategy to recover and put back the missing hunches of experiential intuition so when the developer is in the moments of troubleshooting, they have a better idea about where to look. Understanding how challenges arise within the moments of the activity is critical to our ability to design strategies and solutions that actually work.
Revisiting the Triple Debt Model through this activity-centric lens reveals a deeper layer to what is being represented. There are really two distinct models embedded in here. One model that describes a relationship between human cognition, the code, and externalized artifacts that capture intent. The other captures three types of knowledge that can erode or be missing, corresponding to three types of debt. Let’s consider splitting these into two different models for a moment and letting the relationships breathe.
This first triangle describes a relationship between human cognition, the code (what we’re creating), and externalized artifacts, specifically of intentions being written down. This model is about how the relationships between human cognition, code, and externalized intent work together to support effective action. Now that developers are collaborating with AI agents to write the code, the agents need additional context to understand our goals, constraints, rationale behind design decisions, and what we’re intending to do. If we consider our activity-centric lens for this AI collaborative case, the same principle applies. The value comes from how well the affordances of externalized intent are supporting our collaboration with the agents, and how well they help us reach our goals.
The humans can also make use of this externalized intent, but how that fits into the developer’s activities is different. Consider, what are the moments where developers are reading this externalized intent and using it within their process? When a developer goes home at the end of the day, and comes back the next day, they have to re-orient themselves to the task at hand, remember what the goal is, where they are, what they were intending to do, and rebuild the working context in their head. Externalized intentions could help support this process, but the humans might also need different types of supports than the AI. It’s important to remember, externalized intent is not the goal. Supporting the activity is the goal.
The second triangle of the three debts reveals something different. It describes three different types of knowledge that developers rely on in the moments of their work: intent, cognitive, and technical. Each of these types of knowledge has a similar quality in terms of having “debt-like” cumulative effects where there can be an erosion or loss or knowledge gone missing. If we view this through our activity-centric lens, this means there is some kind of knowledge needed to support an activity, but it is missing, poor quality, or under-supported. For example, a developer trying to understand why a feature is there, and missing the intent knowledge. The intent knowledge could be internal, in the developers head, or missing from their head. The internal intent knowledge may be recoverable from a document if it was previously externalized, or we might be able to recover it by talking to a team member, or going back to our customers.
Thinking through each of these types of knowledge, it became apparent that each type has both an internal and externalized form of the knowledge:
These three types of knowledge directly support the developers ability to make decisions in the moments of the activity. When a developer is exploring, orienting, deciding, creating, validating, or troubleshooting, there is knowledge that supports the process. Developers need to understand 1) the “intent”, the why, the purpose behind the design, 2) the “technical” of what the code is and does, and 3) the “cognitive” conceptual abstractions of how it’s organized, how it works, and all the broader context and know-how that turns understanding into action. Developers don’t need to understand everything at once. They need the knowledge that supports the current task they’re working on, and supports the moments they’re in.
When the developer is in the moments of the activity, the internal knowledge is their embodied felt sense of understanding and intuition, knowing the why behind the design, knowing what the code is doing, and knowing how the concepts relate and what they mean. Some of this knowledge can be externalized. Some of it is impossible to write down. Some knowledge can be recovered by reading externalized artifacts. Some knowledge we might try to recover from an externalized artifact only to realize that not everything can be transmitted through words. When one of these knowledge types goes missing—if we have a build up of “intent debt” or “cognitive debt”—we don’t need piles of externalized artifacts or more understandings to counterbalance, we need to address the very specific missing or poor quality supports. Remember, the value comes from how well these affordances support the activity, and how well they help us reach our goals.
What I find interesting about this variation of the model, is it highlights the relationships between the internal and externalized forms of knowledge, helps us reconsider the ways that different types of knowledge support the activities, and how we might improve our ability to sustain understanding across all three knowledge types as we go. That feels helpful, illuminating even.
By seeing software as an activity instead of an artifact, we start noticing how relationships, interactions, and different forms of knowledge work together to support the developer in their work. By recognizing how the challenges arise in the context of the activity, we can better understand what to fix.
[1] Starr & Storey 2026. Theory of Troubleshooting: The Developer's Cognitive Experience of Overcoming Confusion
