Technical debt and design debt are synonymous, neologistic metaphors referring to the eventual consequences of slapdash software architecture and hasty software development. Code debt refers to technical debt within a codebase.
[From Wikipedia]
Technical debt and design debt are synonymous, neologistic metaphors referring to the eventual consequences of slapdash software architecture and hasty software development. Code debt refers to technical debt within a codebase.
[From Wikipedia]
If you’re doing something that you know that will return to bite you in the ass someday than you’re probably in the “technical debt” department. It can be anything it might mean that no unit tests were written for a feature or that no upfront design was made before coding – depending on the team and project. In fact technical debt is all around us - from missing stages in the CI (Continuous integration) process to quick and dirty coding and missing features.
Avoiding technical debt is close to impossible - unless you are a true craftsman, have a patient and understanding boss (and no deadlines) you might be creating debt as you go along.
But it’s not all bad – because unlike actual debt you might not have to pay interest - some of the time it might actually go away, requirements change or additional code is written and from time to time problem just go away. You might find out that something that was nearly impossible yesterday become easy today just because you’ve learned something new.
I’ve learnt to treat technical debt just like any other known risk - it should be treated and managed - ask yourself what the worse that could happen – will I pay more on a less favorable time (e.c. deadline) and how much time would it take - and decide if it’s worth not doing it right now.
Having said that – there is a catch, it’s way too easy to use technical debt as an excuse. From time to time I get to hear a fellow developer say something such as: “I won’t be doing X because it would take too long and we’re already behind schedule”. The problem with that statement is that I usually have the feeling that he did not think about the consequences of not doing what might be done – because sometime it’s easier not think about tomorrow. The solution is simple – just ask him: “what would happen if you don’t do it” – and then listen – because he might convince you that creating debt at this place and time is ok.
From time to time you might even convince him that he should do what he’s avoiding right now – and by doing so you’ll make your team better.
Happy coding
Labels: Thoughts