Thoughts on technical debt

Published in

Linagora Engineering

4 min readJun 24, 2019

In every projects I have been involved there always have been a time when all I was seeing was limitations implied by current implementation choices, what we generally call technical debt.

Current definition of technical debt

I went through several articles in order to have a good view on how it is defined and managed. They more or less agree on this definition:

Any technical element making harder value delivering.

Depending on the article it comes from:

Poor code quality
Design inadequacy
Use of deprecated technologies
Lack of tests or knowledge
Not fixed bug
Not achieved work

Technical debt is a metaphor: it’s an estimation of the amount of money (spent mostly in man months) needed to refund in order to get it fixed, which grows through time.

Issues of this definition

The first weakness comes from the evolution of the technical debt.

If you want to buy a flat, you may not have all the money, so you go to the bank to get a mortgage. If you look carefully, your monthly repayments should be lower than a rent, summing the expenses should get you a curve like that:

Linear curve (constant monthly repayments)

Or, if you have a bad contract, something like that:

Exponential curve (increasing monthly repayments)

Regarding our technical debt, time is not really the main factor of debt increase:

Slow oblivion
The main maintainer left the project
The code reviewers left the project
New systems depend on it (too much coupling)
Current design becomes unsuitable for new requirements
Technology deprecation

Which leads to this kind of curve:

The second weakness of this analogy is the aim of the debt.

Let’s say renting a flat costs 1.000 € a month and repaying the loan costs 900 €. Buying the flat is the right thing to do since it is beneficial. Now, the interests have raised and it costs 1.250 € a month to keep the flat, what is the rational action to do? Probably sell it, repay the mortgage and rent another flat.

If debt and technical debt were close, why should not we do that with software: keeping the systems that only bring more value than they cost?

Technical debt is only one metric

Technical debt only an estimation the software development inertia. It’s an indication on the price needed in order to get the system from where it is now to where the standards are. It costs nothing, its a potential cost, and it’s the potentiality which grows.

Bringing value to technical debt

In order to give the relevance of a repayment the value it will bring should be taken in account, by looking at the value impeded by this debt.

Let’s take a payroll software split in two parts: the users management and the payroll management. Both of them have technical debt, both of them should have new features, but we have money to repay only one of them.

We have to do the following features:

Account management: making it LDAP-compatible to allow cloud deployments
Payroll management: adding the support of a small city special legislation

Even if most of the value of the software is in the payroll management system we may evaluate that supporting a feature for maybe one or two clients is less important than reaching a larger audience thanks to the cloud hosting.

That’s what make the repayment of account management a priority: it will bring more value to the software.

A good practice is to materialize the repayment in tasks (preferably before taking the decision) in order to distinguish the cost of the repayment and the cost of the added value.

Long term effects of technical debt

Velocity slow down (arbitrary cost per feature increases)
Increase in maintenance costs
Decrease in confidence during software development
Specialization of the development team (hard to enter in the team, to hire)
Lack of support (hard to find help outside of the team)
Software rigidity (it becomes more and more specialized and breaks more and more for each feature)

Afterword

Debt management is a big concern for many softwares, sometimes it can represent up to 90% of the development effort. In order to keep the development moving forward, you should keep focus on bringing value and removing obstacles as they come.

You cannot have a zero-technical debt software. As your software evolves, your standards evolve too, and perfectly valid decisions made at a point of time become technical debt.