So as not to contradict the title of this article, I am going to refer to technical debt as the debt-previously-known-as-technical and hope that doesn’t make this article unnecessarily obtuse.
Debt-Previously-Known-As-Technical
At its core, what is referred to when people talk about debt-previously-known-as-technical is stuff that the engineering team needs to sort out; i.e. an engineering problem.
Let’s explore what kind of stuff falls into this category.
Generally when the team has favoured speed over quality, short term technical decisions get made, and corners get cut, resulting in code that is harder to maintain and expand upon later.
In other cases, a technology becomes obsolete, for example when a library that you might be using is no longer supported, or a better option becomes available. In this case, the existing implementation might, unfairly, be viewed as debt-previously-known-as-technical.
It may be that the underlying architecture and solution design may no longer be able to support emerging use cases, meaning the system might be viewed as legacy or parts of the system may be labelled as debt-previously-known-as-technical.
You may have written a POC or a pilot to get customer traction and, due to delivery pressures, continued to build upon that codebase. Now the codebase has become so large and misshapen what you dread the thought of refactoring it and live with the taunts of creating debt-previously-known-as-technical.
Perhaps you had an intern or a junior developer create part of the system because you were short-handed. They didn’t get the right supervision and / or didn’t have the right technical grounding, and ended up creating debt-previously-known-as-technical.
In fact, if you’re living in the real world and delivering solutions to the market, you’re going to have a hard time not accruing debt-previously-known-as-technical.
Cruft
There are any number of reasons why we might end up with cruft as Martin Fowler called it in his exploration of debt-previously-known-as-technical. Not least of all, humans are fallible and communication is more so, resulting in suboptimal implementations labelled as debt-previously-known-as-technical.
I know you’re wondering how long I can keep this up and whether I will propose an alternative name for the debt-previously-known-as-technical. Bear with me, dear lector. Let’s first look around the room, at other types of debt.
Other Types of Debt
Consider that when in the process of value discovery, there is a change in requirements. This may leave parts of the codebase useless or parts of the system design invalid. Is that customer research debt?
Consider a revision of how billing works, perhaps instead of charging per customer, you decide to charge per API call. Does the hasty revision of the codebase represent debt-previously-known-as-technical or should the sales people have got it right in the first place?
An organisation I worked with sold software to a consortium, within which there were 30 member companies. Instead of arranging a contract with the consortium, the sales staff arranged individual contracts with the 30 member companies. This meant that my organisation was subject to an audit from all the 30 members, rather than simply being audited by the consortium alone. This resulted in a massive and unexpected overhead for the engineering team, but that wasn’t referred to as sales debt.
Consider that there was no quality engineer at the beginning of the project or a shortage of software engineers, but the deadlines were the deadlines, so corners got hacked to pieces. Is that planning or management debt?
If you’re operating in a regulated industry and a new set of regulations is released which are significantly different to the previous ones, is that regulation debt?
Lastly, there will be human errors of judgement across the organisation which will find themselves into the codebase. Is that just life-happens debt ?
Conclusion
Debt is debt, and assigning responsibility to one function within your organisation will cause divisiveness. This can only lead to a downward spiral of productivity and a blame culture where CYA (Covering Your A$$) is more important than delighting your customer.
Calling it technical debt, means everyone sleeps easy except the engineers, because the hidden message is, they broke it, so they should fix it. This is simply not true.
I don’t know what it should be called, perhaps just debt or simply cruft- it doesn’t matter what it’s called as long as everyone takes holistic responsibility for the end product. Perhaps there is no debt, having something called debt implies it needs to be paid back. Any debt should be considered alongside customer needs, if it causes a hindrance, fix it, if not, don’t.
In conclusion, debt will accrue along the way. Inspect and Adapt, look ahead, work together, and we can get much further.