Here I revisit how interaction cost explains technical debt as the difference between understanding and implementation.
(…inspired by hallway conversations at YOW! Tech Leaders Summit about Ward Cunningham’s original definition of technical debt, and the value of software code as either a durable asset or an ephemeral expense…)
Interaction cost is my term for second-order costs that arise in activities with interacting elements. In this category, I would put design and change, and software development, as both design and change.
\[C=F+Vn+In^2\]
Activities with interacting elements
Design has interacting elements because each decision in general affects multiple others. I first appreciated this in parametric CAD software: certain choices for parameters precluded other choices structurally. If we define one straight line with reference to another, by the angle between the lines and the point of intersection, then we can’t make the lines parallel. If we make them parallel, we must specify a distance offset instead of an intersection point.
I then saw this in multi-disciplinary automotive design. To illustrate, the decision cascade might start with a styling concept and a powertrain, then body structure and chassis, then we start to pack in seats, fuel tanks, etc. At this point, improvements in one element start to impact other elements, like increased legroom or safety but reduced range. Various departments start to negotiate and tradeoffs must be decided. Getting down to details of HVAC and wiring routing, these disciplines must generally accommodate higher level decisions, but at some point a conduit becomes too narrow for its function, and this constraint must now cascade back up to revised higher-level decisions.
We might also layer in secondary considerations, like manufacturability, for instance whether paint wets and can drain out of holes in the body structure when it is dipped into treatment baths, and make further adjustments accordingly, which might also have cascading effects. With these examples, we start to see the complexity of the design task is determined by the number of interactions between design elements. Reducing or decoupling the number of elements simplifies the design task.
Change in organisations, or design and re-design of an organisational future state, also requires consideration of multiple interacting elements across dimensions of people, process, systems and data. We might approach change with the intent to cascade change design down from higher-level concerns to contextual details, but with people having agency close to the work, we should always be prepared to cascade their local innovations outwards and upwards.
Software development is also a design exercise. The resulting design is a system with interacting elements of code. The process of designing the system is also a change process defined by a sequence of interacting commits. The system that we design and codify in development, we then deploy into production.
Going to production, we experience a phase change from design, as the system now operates as a largely automated factory that manufactures user experiences and data products on schedules or on demand.
Factory maths breakdown
Most managers are familiar with “factory maths”; fixed and variable costs.
\[C=F+Vn\]
At some scale of units n, variable cost will dominate, so we shift variable cost from coefficient V to the fixed overhead F for lower cost overall. The managerial class learns this in MBAs.
So factory maths applies to software in production/operation, as above, but not the design/development/change activities. While managers’ MBAs and factory intuition may serve them well in software production/operations factories, the same intuition and management heuristics do not work for design/development/change activities, because they break factory maths.
Design maths in its element
Design/development/change activities need “design maths”; they must include interaction cost between elements. For n elements, the number of interactions is proportional to the square of n, hence we now write cost as:
\[C=F+Vn+In^2\]
And now for some scale of elements n, interaction cost will dominate. Variable cost is still real and tangible as a separate component even when there are no interactions to consider, and indeed the place where interaction cost shows up is in the varying variable cost of each new design, development or change activity.
For these reasons, you won’t find interaction cost unless you are looking for it.
For these reasons, management may struggle with interaction cost or technical debt. The factory heuristic of shifting variable cost to fixed does not in general address interaction costs and indeed may be counterproductive.
Instead of variable cost, economists would rightly call what we’re talking about here marginal cost, as the rate of change of cost per unit of production. Differentiating our cost equation by n, we see marginal cost is more than just the variable cost of factories, as it increases as the number of interacting elements increases.
\[dC/dn=V+2In\]
So we need better management heuristics for design.
Design cost heuristics
Better heuristics for managing design/development/change activities shift interaction cost to variable cost. The single factor I is actually the sum of all of the pair-wise interaction costs ijk, so we can either reduce every ijk by some amount, or we can dramatically reduce ijk for certain j, k, effectively zeroing out interactions. An effective way to zero-out interactions is remove elements n from the system entirely!
This leads to the following management heuristics for interaction cost, or technical debt, from Scaling Change Spoiler:
Socialise
We take a variable cost hit for each element to help it play more nicely with every other change. This reduces the cost coefficient I but not the number of interactions (n2).
Screen
We only take in the most valuable changes. Screening half our elements (n/2) reduces interactions by three quarters (n2/4). We need to do this on a schedule or when new elements arrive, so it adds to variable cost.
Seclude
We arrange elements into separate spaces and prevent interaction between spaces. Using m spaces reduces the interactions to n2/m. This is one of the functions of architecture and modular design. We need to do this on a schedule or when new elements arrive, so it adds to variable cost.
Surrender
Like screening, but at the other end. We actively manage out changes to reduce interactions. Surrendering half our elements (n/2) reduces interactions by three quarters (n2/4). We need to do this on a schedule or when new elements arrive, so it adds to variable cost.
These look a lot like the things you might do to manage technical debt, but now with extra mathematical rigour!
Note that, while in this article we assume cost coefficients are positive or zero, depending on how we allocate costs between variable and fixed, good architecure, tools and libraries have the potential to make pair-wise interaction costs negative, ie the marginal cost becomes less than the variable cost.
Understanding-implementation alignment
Following our long story arc back to the notion of technical debt as the difference between understanding and implementation, we now see how cleanly this is modelled by the interaction cost term.
The closer our implementation is to the domain, then for each new design element or change, the fewer costly pair-wise interactions, or misaligned effort, we will incur. This holds in either closing the remaining delta to a static domain, or evolving our implementation to track a continuously evolving domain.
\[dC/dn=\text{aligned-effort}+\text{misaligned-effort}.n\]
\[C=\text{overheads}+\text{aligned-effort}.n+\text{misaligned-effort}.n^2\]
When we have good alignment, the marginal cost of each new element will be almost exclusively the variable cost, as misaligned effort approaches zero.
As I observed previously, there is a neat mathematical analogue between interaction cost and rotational inertia (M.r2). Both are dead weight far from our axis of change, impeding our ability to pivot. So, with the understanding-implementation alignment framing, I think we could dub interaction cost conceptual inertia.
Note that the interaction cost framing does not require poor implementation or shoddy coding to explain technical debt. While these things will make variable and interaction costs worse, conceptual inertia only requires the potential for elements to interact.
Durable assets and ephemeral expenses
How should we treat the software systems we design and change, especially in this era of AI-assisted code generation, which may allow us to treat code as disposable, if not designs? Which parts should be durable assets and which ephemeral expenses? I think I’ll tackle that in connection to conceptual inertia next time, but please check out my thoughts on Antifragile AI Architectures in the meantime.
Leave a Reply