From Technical Debt to Design Integrity
Despite being widely used in the software development community, I think the technical debt metaphor has been misused, leading to annoying unintended consequences. Maybe, we should look at possible alternatives.
The original context
The original technical debt metaphor comes from Ward Cunningham as a tool to explain the refactoring their team was doing on a financial product. Being in the finance domain, Ward picked a metaphor that resonated with the audience, and debt was fitting just right.
The metaphor worked well in that context and later became popular in the software development community, maybe because we all struggle to explain the motivation for refactoring to non-technical colleagues.
However, adopting the metaphor in different contexts may not work that smoothly. The implications of debt are not always understood or internalised equally, and the word itself tends to be associated unconsciously with different connotations that may or may not be helpful.
Debt somehow implies an obligation to repay. In the original scenario, the metaphor resulted from a deliberate choice to anticipate feedback with a simpler exploratory implementation, eventually delaying the work to turn the draft implementation into production-ready code. But not all debt is meant to be paid in the real world. Companies can go bankrupt, investors will be protected by limited liability, stockholders will lose their money, nations can still run with a public debt bigger than 100%, and in some sectors, when you go bankrupt, you rename the company and start over.
A debt with the mob?
A few years ago, I tried to play differently with the tech debt metaphor in the past by saying, “Technical debt is a debt with the mob.”
I was trying to highlight that we may not have the luxury of negotiating the repayment deadlines or interest rates, eventually spreading repayment on a longer time horizon. Instead, we are putting a little of our future freedom in the hands of somebody who is not supposed to play by the rules and will decide when this debt needs to be repaid. It should also hint that it’s quite a dumb idea to borrow from the mob.
It suggests backwards thinking
The mob idea was fun, but the most annoying consequence of the technical debt metaphor has to do with the perspective it seeds. Being in debt has a somewhat negative connotation: criminals are supposed to pay their debt to society, for example. The technical debt metaphor wasn’t referring to it. Still, our brain is an association machine, and we may unconsciously connect technical debt with blame, inadequacy, and guilt, triggering the associated bad feelings in our bodies.
Moreover, when we discuss technical debt, often somebody remarks that technical debt refers to an intentional decision to borrow some time, while most developers — including me, quite a few times — use it to refer to inadequate code quality, and Code Cruft may be a better term for it not to mention the fact that what some people call technical debt is just bugs and we shouldn’t be discussing them in the same way.
This is when I lose interest in the discussion. Not because somebody is correcting my wording 😬, but because the whole discussion becomes pointless. It leads to a boring and meaningless dissection of How did we get here? that resembles the typical left-wing parties’ sterile discussions.
The point is not to dissect the many categories and histories and technical debt, or to dwell on the past. This is history. The point is, What do we do now?
You may find similar ideas in this online talk from Emily Rosengren at GOTO Chicago 2023. I stumbled upon it while looking for references and found I am not alone in feeling this pain.
It implies convincing
This is the issue that disturbs me the most. Many people were infected by Ward Cunningham’s idea and thought: “Great! I should use the same idea to convince my product owner!”
No, you shouldn’t
And the problem is not the metaphor, but the silent poison of the word “convince”. It subtly implies that someone with expertise in software engineering is trying to explain to a less expert person, and this person is deciding. And this setup is wrong.
- The decision-makers, probably with a business background, now need to decide according to some principles that are not part of their experience. They can do so driven by trust or emotions, but they will fall short if the scenario changes. Remember that refactoring, by definition, is a pure financial loss in the eyes of a financial stakeholder: you’re asking company money to do something with no observable effect on the outside. We all know that it can — and probably will — have a positive effect on the whole ecosystem, but financially, it’s more like Somebody is asking time and budget to do something invisible we don’t understand. Will your product owner stand up to defend an idea they don’t completely understand when the C-Levels jump in?
- The software engineers are delegating a responsibility that should be theirs. Sometimes, engineering is subordinate to the business side (and it never ends well, in my experience). Other times, the relationship is more balanced, but engineering gets trapped in a negotiation game and ends up bargaining on principles or asking permission to do the right thing. If you are a professional software engineer and know you’re doing the right thing, you shouldn’t ask permission. You know why it’s right.
Engineering responsibilities should belong to engineering. We are the ones experiencing it. We should be the ones owning the problem and its solution, too.
You may want to look into what Marty Cagan has advocated for years in the product space.
Put another way, the Technical Debt metaphor addresses an organisational problem you shouldn’t have, but the popularity of the metaphor implicitly reinforces the wrong organisational setup.
You won’t convince anyone anyway
Whenever the discussion points to dysfunctions in the organisation, we lose a big audience: changing roles and job titles is beyond our possibilities. Unfortunately, if you’re using the Technical Debt metaphor as a way to play by the rules, you still have very little chance to succeed.
The non-scientific Venn diagram of software engineers and people with excellent persuasion skills should already tell you something.
But the sad story is that it doesn’t matter how good you are in clarity, rhetoric, and speaking the business language: you won’t convince anyone anyway because there’s very little in your audience’s past experiences to connect to.
Here is a small representation of the complex stack most software developers deal with daily. The shape doesn’t matter. What matters is that:
- It keeps piling up;
- It should be working despite possible changes happening anywhere in the stack.
Changes can happen for many reasons: new business requests, component upgrades, random failures, and security patches, but they shouldn’t be ignored. Being accountable for a software stack means subscribing to an endless feed of nasty surprises.
This mess is why testing automation is necessary: we need help to keep this complexity under control and to be able to sleep at night.
However, there are few examples of such long-living complexity outside the engineering domain. One can be “writing a book on EventStorming getting caught off-guard by a pandemic”, and another can be “being an undercover sleeper spy with a fake identity in an enemy nation for 30+ years”, but they’re rare.
Most business experts never experienced something as complex as a lively software stack.
When we describe technical debt, we assume that our listener will empathise with the feeling of vulnerability associated with the fragility of the codebase, spiced up with stress, guilt, and imposter syndrome. But it won’t happen because they don’t share any relatable experiences (unless they’re a sleeper, of course)
They will say, “I know what you mean”, but that’s not true. Whatever you think you’re seeding in your pitch for technical debt won’t last long.
The Technical Debt metaphor perfectly describes the trade-off on a single feature. The compound effect of many piled-up trade-offs is a completely different story. Did you borrow from the Russian mafia, hoping to buy yourself some time to repay the Italians?
Try Design Integrity
If Technical Debt has so many unintended consequences, maybe we should consider some alternatives instead. The notion of Design Integrity is my favourite one.
In a very naive way, we can consider it the opposite of technical debt, but the current (yet unstable) definition is:
Design Integrity describes how much the current codebase fits its purpose.
No past, no guilt. Just, “How close are we to where we should be?” Or, “If we were redesigning this from scratch, how different would it be?”
The answers can open a can of worms in both directions: from a non-pragmatic rewriting frenzy to dogmatic blindness to alternatives. But the question still holds.
Future-oriented
The idea of Fitness for purpose is key. Ideally, we can borrow the concept of a neutral stance from martial arts: a body posture that can be used as a starting point for both attack and defense, basically making you ready for anything.
Put another way, this position gives you the highest optionality about what’s more likely to happen.
Likewise, design integrity is a way to assess your codebase’s fitness against the potential challenges that are likely to happen.
How did we end up here becomes quickly irrelevant. This is today’s codebase; these are the incoming challenges. Are we ready?
And, of course, we all know that the future is uncertain and that our roadmap will be a context-dependent combination of residues from past procrastination, new business challenges, bets, and wild dreams. And they all can change. But this is what we know today: to have a more sophisticated look into the unknown, you might have a look into what Barry O’Reilly is exploring with Residuality Theory.
A virtue, not a fault
Design Integrity has a more positive connotation than debt. Instead of something to repay, it is something to achieve and preserve. While achieving it can be tricky, holding it could become a healthy habit, like getting progressively back in shape and staying there.
But instead of losing weight, we are unlocking options along the way. And keeping options open sounds like a sound business strategy to me.
