Some real-world analogies for describing technical debt
A debt is usually something we do not enjoy. The de-facto association is with a financial debt, where we trade money now versus paying back later, with interest.
Technical debt shares similarities. What we get now is a short-term software delivery at the cost of extra complexity. The latest will require a future refactor to pay it back.
We can make another analogy to represent the extra effort required when technical debt is present. Looking at the two kitchens below, in which one would you rather cook?
I assume you would select the clean one, right? 😊
Where can we find technical debt for software?
Technical debt lies in the various internal and external software attributes, from architecture to operations, and its organizational element.
As you can see, we do not talk only about the code or internals of the software. It requires a global perspective to see the problem in its entirety.
Can we find distinct types of technical debt?
Defining technical debt is a prerequisite for managing it effectively.
We can first differentiate intentional and unintentional causes, useful for understanding if problems lie more in organizational culture or skills, visibility, and reporting.
The second level differentiates technical from organizational reasons that would have different root causes and possible solutions.
In specific contexts, we can separate legacy and inherited causes. Identifying what is in control and out of control is key for technical debt management in this case.
What tends to happen with technical debt?
It usually starts with uncomfortable questions for software engineers.
The worst-case situation is to be unable to maintain the system. The only option then is to replace the system completely.
Else, the team needs to try delivering value in an overly complex ecosystem, where every change is a risky, painful, and slow process.
Speed, but at which time horizon?
Taking another analogy with sport and running, you can visualize technical debt as the extra weight you need to carry for each footstep.
The more you have, the harder it is for you to run at speed and overtime.
Addressing technical debt will enable you to benefit from the speed and quality of delivery.
Speed is a question of perspective. Here, we are talking about a structural performance that enables significant business value in both the mid and long-term. Not a short-sigh approach.
What can we gain by addressing technical debt properly?
The first value is and must be to achieve business goals.
In practice, the software delivery process will be faster and of better quality. The software delivery process is more predictable by having shorter feedback loops and measurements.
Managing your technical debt is also beneficial to your team, organization, and atmosphere.
In ideal situations, you manage to create positively reinforced feedback loops.
But how can we end up with technical debt?
Accumulating debt does not happen overnight: this results from day-to-day decisions that end up like the plates in the kitchen.
Software technical debt is harder to feel, touch and experience. It is one reason it is easy to ignore it versus a real kitchen.
Another reason lies in human behavior. We are not good at forecasting the future impact of the actual decision. It also supports getting into financial debt under other urgency, emotions, etc.
Organizational culture, values, and pressure are very influential
The organization and its culture are also vital in technical debt.
The ones that value short-term delivery, hero actions, and agile fallacies tend to accumulate a huge technical debt silently.
They create reinforced negative feedback loops that tend to be dangerous for organizations.
We need to look for early warning signs such as repetitive delays, low morale, turn-over. But in fact, it is usually late if you can find symptoms.
Therefore, we propose a more proactive approach.
Looking forward to applying technical debt
This article shared the reasons for caring about technical debt, introducing its key characteristics, causes and benefits.
In the next article, we will share how we concretely work on managing the technical debt.