Rethinking Technical Debt: Grasping at a New Metaphor
Continued from Rethinking Technical Debt: A Path Forward
If I think of a subdomain as terrain and the value stream as the path on the journey I want to take, then technical debt is just one of many obstacles. I’m drawn to the journey metaphor as a means of capturing technical debt, or really a generalization of technical debt, to provide a model for thinking about the broader qualities within the domain that help or hinder my pursuit of an objective. I also appreciate that the journey metaphor doesn’t attribute over-prescriptive solutions or assumed consequences of those qualities. If there is an obstacle in your path, there is no simplistic “best practice” that determines whether you should go over it, around it, through it, or even abandon the journey altogether. It depends on the nature of the obstacle and the value of what’s on the other side. It also leaves open the possibility that some features of the landscape, desirable or otherwise, isn’t on your journey and can simply be ignored.
Of course, this metaphor isn’t entirely novel. I consider that one of its strengths. There is plenty of prior art that relies on a similar metaphor: Value Stream Maps, User Journeys, Wardley Maps, in addition to an entire series of mental models that include business climate, north stars, team topologies, and roadmaps. Software is often compared to travel, exploration, and geography, so much so that I wonder if cartography wouldn’t serve us better than architecture as the way to think about IT at scale. I don’t believe the prevalence of this metaphor is a coincidence of technological or literary history, but rather an expression of something intrinsic about the human mind. In The Extended Mind: The Power of Thinking Outside the Brain, Annie Murphy Paul convincingly argues that, because humans evolved (of course) in a physical world, our analytical skills are strongest when we frame abstract concepts in physical terms. Our ability to create effective solutions to complex socio-technical problem is enhanced if we can set them in physical space, both literally and figuratively. Concretizing abstraction allows us to better utilize the problem solving skills that have evolved in our species for millenia.
Next, I’d like to discuss some ways to physicalize software and organizational architecture, what existing frameworks are available to adopt and adapt, and concretely tie it all back to the Debt Metaphor and its limitations.
