The virtues and limits of the financial tech analogy
The term technical debt was coined by Ward Cunningham who compared it to financial debt, in the sense that we decide to gain an immediate advantage (we produce something faster now) in exchange for a future obligation (fix whatever cruft this decision has introduced into the system). There is some clear fundamental value in this framing, and it can be very useful to build common understanding between business and engineering about what tradeoffs are appropriate.
But there are also many ways to make the analogy break down. For example: the fundamental part of a financial loan is that the interest rate and due dates are clearly defined upfront, whereas in the case of technical debt no such clarity exists. Additionally, technical debt interest manifests in two ways, both of which can be crippling. The first one is the effort it takes to "get the system right”, which is tricky because this tends to grow exponentially the longer it is deferred, as more complexity is added on top of the already technically indebted system. And then the second one is the increased friction to change the system to fit new business needs due to whatever shortcomings the inappropriate solution is causing.
A hypothetical scenario where the word technical debt has become controversial
But let's go beyond quibbling with the analogy, which while being fun, does not bring the insights we are after. Let's explore how the discussions about technical debt usually play out in real-life situations. This scenario is a fictitious one, but you may find it all too familiar.
The topic tends to be brought up after friction between business and engineering has increased to the point that the organisation needs to look at why new development seems to take so long. When it does come up, business is usually completely blindsided by it, which further reduces trust on both sides. This is because there is not a clearly identifiable and documented point in time where both business and engineering reached an agreement that there are two possible alternatives and we will choose the one that is more expedient, but may have future repercussions.
Once tensions run a bit higher, you may also notice how the term technical debt takes on additional interpretations that go beyond the initial analogy:
- Engineers can overuse the term to refer to code they don’t feel comfortable with - it may be done in outdated or unpopular frameworks, they may consider it too simple or too complex, or perhaps it is just because they would have solved it in a different way.
- Business side can understand technical debt as permission to deliberately lower quality in favour of quickly adding new features. This is closer to being foolhardy than a deliberate strategic decision.
When asked for explanation, engineers then scramble to succinctly express all the ways in which it is hard for them to be effective in bringing new features to the system, and reasons span the gamut from poor documentation, outdated dependencies, changing requirements, bad code practices, monolithic architecture or poorly designed microservices architecture, or maybe how that developer who no longer works here did not know what they were doing.
And they most likely also say that they tried to sound the alarm of trouble on the horizon, but they were not listened to. But to the business, it seems less like a loan they took out and more like the mafia showed up saying - nice business you have here, it would be a shame if something happened to it. You better pay up, or you may be looking at production outages and a backlog of unreleased features a mile long.
At this stage it may make sense to take a step back and change the approach.
A better way to look at the problem
The technical debt metaphor has this fundamental flaw: the word debt has a negative connotation to it, and if there was no mutual agreement to take it on, it can quickly put you in the mindset of looking through the historical records about who is to blame. Additionally, there is an implicit idea that permission has to be given to pay it back, and that the permission comes with limitations, such as a percentage of time developers are allowed to work on technical debt, or a temporary freeze on new features.
Here is a better way to look at it. The three most important reasons why software systems become hard to change are these:
- The underlying reality has changed, or perhaps our understanding of it has improved. This is normal and expected - the company's business environment is constantly changing and we must adapt to it. What engineering needs to make sure is to understand how these changes affect the system, because it can sometimes be subtle, and share that information.
- The engineers lack time and possibly skills to keep evolving the system according to strategic business needs without compromising quality. And it tends to be under-appreciated, even among engineers, how difficult that is to accomplish. Which brings us to the next point.
- Software engineering is hard. Modern software systems are built on top of many interconnected components that are all evolving over time, and managing this complexity is something that has few analogies in business. And this is necessary to do just to keep things from breaking.
The latter two especially, but also the first one, can only be mitigated by providing enough time and support for engineers to do the work and grow in their expertise. They should be primarily viewed by the company - and themselves - as stewards of the system that supports the company’s business, not merely implementers of requirements handed down to them.
As Alberto Brandolini suggests, let's move away from the notion of technical debt entirely and replace it with something like Design Integrity, which he defines simply as "how much the current codebase fits its purpose". And then consider that developing that capability is a fundamental business need and that acquiring it requires engagement from both sides.
Changing the underlying culture is a hard but essential step
To summarise: a culture where business is only concerned with issuing requirements towards engineering while engineering is not willing or able to own their responsibility to guide the development of the system according to strategic needs is not conducive to developing the kind of digital building capabilities modern companies need.
Instead companies should encourage collaboration between business and engineering, where they establish a common understanding about how to solve the challenges of the day, and how those different solutions may affect the systems’ design integrity, both in the short and long term.
This can be daunting for managers as it requires relinquishing some amount of authority, but it is not a trivial thing for engineers either, because some may see it as leaving their comfort zone. But if we accept that the principal task of engineers is to make sure the system’s design fits its purpose, then they need to be brought into the fold and get aligned on what that purpose is. This is where we can bring in ideas from Product Management thought leaders such as Marty Cagan, who has been a powerful advocate for making sure that engineers intimately understand the business challenges and the product strategy so that the technical solutions they provide are aligned with them. One important benefit this leads to is that it not only improves decisions about what to build, but also about what not to build, because the anticipated value may not offset the complexity it would bring to the system.
Be on the lookout for counterproductive communication patterns
It is quite common for companies to understand that they should be striving towards a more collaborative relationship between engineering and the business, but less common for them to understand how their existing culture, mindset and even the concepts they use in everyday work prevent them from achieving that. I believe the term technical debt can be an example of that, as it tends to be a lightning rod for counterproductive dynamics in your software teams. So if you observe that the topic comes up frequently in contentious conversations, rather than strategic and collaborative ones, try to dig a bit deeper for the root causes. Dealing with them may be what you need to unlock the necessary collaboration that will lead to permanent improvements in the effectiveness of your digital strategies.
.webp){kind=small}
