Technical debt can come in many forms, but is your legacy codebase really technical debt? If you make decisions based on the knowledge you have at the time, can the problems these decisions cause later (either weeks, months or years later) be called technical debt? I don’t believe so. If we’re going to use the analogy of taking on a financial burden, then you wouldn’t be able to take on a financial debt without knowing about it and, if you somehow did manage to do that – would you even be responsible for the debt (if we think about how those who took on a credit card with PPI are now claiming all that money back)?
There is plenty of discussion about what technical debt it on the internet. For example,Wikipedia sez:
Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future.
Martin Fowler describes it as:
In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.
My question is then, if you write code, or architect an app to the best of your ability, with the best code you can – no cutting corners, or missing tests – is it technical debt when you come back to the code months (or years) later, and it requires huge refactoring because it’s out of date?
I would suggest that no, it isn’t.
If it’s part of your system that hasn’t required work since you wrote it, then it’s simply legacy code. Technical debt is smelly code that you create deliberately. That is, you need to cut corners, or hack stuff, to get your code out of the door quickly. If you know you’re not writing the best code or architecting your application correctly, but you do it anyway, that is technical debt.
The thing about technical debt, like real debt, is that over time, intrest accrues. Let’s say that on day one, you deliberately create some smelly code in order to get something deployed quickly. You decide to fix it the following week. A week later, it takes you two days to write the code correctly.
Let’s say, however, that you couldn’t fix it a week later – something more important came up – instead, you could only fix it a month later. Now, because the codebase has moved on – other devs have committed code, you’ve committed code etc etc – what would have taken you two days to fix a week after you wrote it, might now take you five days to fix (assuming that for every week, the code gets complex enough to add another day to fix it). This means, your interest on this technical debt is roughly one day a week. So, if you leave technical debt for months, it’ll take much, much longer to fix and, depending on your position, every new dev you add to your team will compound that interest, until it spirals out of control and you end up declaring bankruptcy and re-writing the codebase from scratch.
Sound familiar? Might as well do it properly the first time round…