I’ve used 5 methods for dealing with technical debt. Which was the best?
I’ve worked in software engineering for over twenty years, and in that time I have seen tech debt handled in lots of different ways — some good, some bad and some ugly.
I’ll explain the pros and cons of each method as I see them, and which I think was most effective — even if I don’t think there is necessarily a right way.
What is Tech Debt?
Wikipedia definition for technical debt is below, but I think there is still some nuance and ambiguity around this topic.
“The implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer” https://en.wikipedia.org/wiki/Technical_debt
This definition largely makes sense, but it’s not completely accurate for me. The tech debt may not be something that was chosen — it could the legacy from ex-employees, or could have been introduced because of a mistake in design or execution. Both of these cases lead to undocumented tech debt, which may be invisible. I’ll talk more about how to capture tech debt below.
Equally, the debt could be more of an opportunity. Most people learn every day, so the code you wrote years ago is likely to be of poorer quality than the code you write…
