Rethinking Technical Debt: A Path Forward
Continued from Rethinking Technical Debt.
When a developer plays the tech debt card, it can be a way of shutting down conversation, a means of avoiding difficult discussions about tradeoffs. Yet it often reflects a real concern. What I have been puzzling about is how to evolve a real concern into one that is actionable. To get to that point, I believe we need two things:
- a better vehicle of analysis that can transform developer anxiety into deeper understanding
- a new metaphor or language, or both, by which engineers can explain the consequences revealed by that analysis.
The first of these is probably the harder of the two. It will require diving into challenging questions about risk, including low probability, high cost events like security breaches, and provider outages. It will require a critical lense for addressing important but frustratingly abstract software development issues like code expressiveness and consistency. It will require taking a collection of highly disparate concerns and comparing them or enabling others to do so. Ideally we could develop a comprehensive model, a matrix into which we could enter various metrics like lines of code and numbers of customers and get back a stack-ranked list of priorities. Since we’re dreaming, each priority would have an associated solution. As is so often the case in software, an immature discipline in many ways, we’ll have to start with a set of heuristics.
DDD provides the concept of core domain as a classification for the business differentiator, the key area of your organization that holds the key to customer value and should therefore receive the most care and attention. It’s a good starting point for questions of focus and resource allocation but it also seems like an insufficient means to characterize complexity in modern organizations. The addition of classifications like “supporting”, “generic”, and then further classifications like those Nick Tune provides in his 2020 article on “Core Domain Patterns” helps add some nuance, but we can go farther still. I have come to believe we would be well served to draw out the qualities of our subdomain, rather than simply try to fit them into classifications. By qualities, I mean descriptions of behaviours, both intrinsic and desired, that can help us determine what to expect and how we might need to act in order to achieve our goals. We might decide that a subdomain is highly unstable, perhaps because it is in an emergent field without well established norms. As a result, we might need our business logic to be responsive to change. In contrast, we might assign rigidity to an area of our business that does not change very much, but we need to get things right by some externally-provided definition, encouraging us to aspire to the quality of auditability or consistency.
In order to evaluate the relative importance of a claim of technical debt, we can start by creating bounded contexts to draw lines between smaller areas of our domain. If you haven’t done this exercise before, you have some catch-up work to do, but you can also use quality attribution as a means to do that work. In general, DDD literature considers a bounded context as the primary means of demarcating a lexicographical boundary. While important, differences in terminology are just one consequence of crossing one of these boundaries. Shifts in performance characteristics, risk profile, competitive landscape; these can all be a compelling hint that you have just crossed a line between contexts.
So how do we find these lines and what do we do with them once we’ve found them? Organizational workflow is always a good entry point. Event Storming is a low-lift, high value place to start. Annotating the results of such a session with boundaries that indicate change in existing and/or desirable qualities provides a visual representation of the flow and where the lines are crossed that can be useful for group discussions of the domain and how it compares to organizational structures or product boundaries. It also serves as a kinesthetic engagement tool that can provide the moderator hints to the nature of the socio-technical environment of your organization. In his DDD workshops, Alberto Brandolini talks about observing workshop participants planting themselves in front of parts of the workflow they care about to signal ownership or territoriality. The simple act of adding a couple of vertical strips of masking tape and a cluster of notes with qualities in the spaces between can be enough to start the conversation about how qualities shift as workflows unfold.
What does any of this have to do with Technical Debt? By letting go of the metaphor and instead focusing on the gaps between desirable and actual qualities within a bounded context, we’ll have a much better chance at having a coherent conversation about value.
Continue reading part 3: Rethinking Technical Debt: Grasping at a New Metaphor
