Technical debt is not debt; it’s not even technical
markgreville.ie
Technical debt is not debt; it’s not even technical
1–10 of 147 posts
Re: Technical debt is not debt; it’s not even technical
#2I'm not particularly fan of one person coining a term and have everybody agree on that, I think every team should create its own glossary of terms and always compare against different authors that may have gone deeper analyzing a given topic. There are some terminology that makes sense for some contexts and other that simply not. It may make sense for me to call something in a certain way because my team understands and we all have agree on what are we referring to, instead of having someone to tell us how to call things.
I really like this kind of epistemological analysis on tech terms, specially those that we use all the time and that we think we understand, but mainly for going deeper on a topic and analyze.
Re: Technical debt is not debt; it’s not even technical
#3I agree with general sentiment that people mean different things by "technical debt" but don't buy the argument for the title.
Article says: "Debt repayment has three properties that are straightforward to grasp — principal amount, interest rate, and term [...] when comparing technical debt, there is no agreement on the principal, [...] there is no concept of an interest rate [...] , term length isn’t a fixed concept"
However, there are generally accepted meanings of the those terms for the technical debt:
- The "principal" is how many things is wrong with the code. It could be measured in features ("We need to implement unit tests and database layer to clear technical debt") or in time ("it will take 6 FTE-months to clear our technical debt")
- While "interest rate" is rarly used, "interest payment" is common -- this is extra time spent implementing the new feature. One can say: "This feature would take 1 day if we had database layer, but because of technical debt we own, it will take 4 days instead". In this case "3 days" is the "interest payment"
- Not all debt has fixed term. "revolving debt", like a credit card, has no term at all. Technical debt is like that as well.
(Of course getting the actual values for "pricipal" and "interest payment" is very hard and no two people are likely produce the same estimate for them. But even if don't know the values it does not change the fact the the terms are defined well -- so this is very much a "debt")
As for "not even technical" part: I am going to argue that everything indirectly affects competitiveness, costs, customer satisfaction etc.. A leaking roof will decrease morale, decrease development speed and can even kill the company. Judging by consequences does not really bring anything useful to the table, so if you want to qualify the term, let's use originating action. "Technical debt" if we don't have any tests. "Financial debt" if we took money from the bank. "Organizational debt" if we are not creating the positions we need, and so on...
Re: Technical debt is not debt; it’s not even technical
#4I agree with general sentiment that people mean different things by "technical debt" but don't buy the argument for the title. Article says: "Debt repayment has three properties that are straightforward to grasp — principal amount, interest rate, and term [...] when comparing technical debt, there is no agreement on the principal, [...] there is no concept of an interest rate [...] , term length isn’t a fixed concept…
You make a god point about the generally accepted meanings for terms for technical debt. However, there are lots of companies ive worked in (and more I know of) that try to scientifically calculate a numerical value for Technical Debt. At best, it's a metaphor, a mental aid to understand a loose concept. Any attempt to calculate implies that there is some 'best solution' that should be achieved. However, this almost never exists, any best solution is in the eye of the beholder, it will differ depending on whether you are a developer, DevOps, client, manager, CISO, barista, best friend, pet.........
Re: Technical debt is not debt; it’s not even technical
#5I'm not particularly fan of one person coining a term and have everybody agree on that, I think every team should create its own glossary of terms and always compare against different authors that may have gone deeper analyzing a given topic. There are some terminology that makes sense for some contexts and other that simply not. It may make sense for me to call something in a certain way because my team understands…
Great point. If we name things, we should understand what the name means, and just as important, what it doesnt mean. We all know naming is difficult, which brings to mind the old joke -
"what are the 2 hardest things in technology?"
"Cache invalidation, naming, and off by one errors"
Re: Technical debt is not debt; it’s not even technical
#6I agree with general sentiment that people mean different things by "technical debt" but don't buy the argument for the title. Article says: "Debt repayment has three properties that are straightforward to grasp — principal amount, interest rate, and term [...] when comparing technical debt, there is no agreement on the principal, [...] there is no concept of an interest rate [...] , term length isn’t a fixed concept…
Nice analysis, but I think you missed the most important difference between real debt and technical debt: with real debt you owe someone else; with technical debt you owe yourself.
Re: Technical debt is not debt; it’s not even technical
#7I agree with general sentiment that people mean different things by "technical debt" but don't buy the argument for the title. Article says: "Debt repayment has three properties that are straightforward to grasp — principal amount, interest rate, and term [...] when comparing technical debt, there is no agreement on the principal, [...] there is no concept of an interest rate [...] , term length isn’t a fixed concept…
Nice analysis, but I think you missed the most important difference between real debt and technical debt: with real debt you owe someone else; with technical debt you owe yourself.
Not necessarily as it is passed down generations. This is in fact when it becomes more painful.
Regardless, technical debt was always clearly a metaphor. I can imagine many other metaphors where one may owe something to oneself, eg, “sleep debt”.
Who cares if it conforms to the definition of the Bank of England?
Re: Technical debt is not debt; it’s not even technical
#8Ok, so the article basically said to comment before reading. So technical debt is anything in your codebase or infrastructure that makes things harder in the development process or limits the set of features that you can offer. You live with it because this limitation is not completely blocking, otherwise you would actually fix it, but you also don't want to forget about it or pretend like it doesn't exist. So you track it and call it technical debt, it's effectively an IOU to your future self.
Re: Technical debt is not debt; it’s not even technical
#9The idea that debt has a specific and clearly-understood principal, term, and interest rate is a very narrow corporate-finance perspective. Many forms of debt in many cultures do not work like that (consider the notion of a "life debt"); you have a fuzzy sense that so-and-so owes so-and-so, but no specifics about exactly what or how it would take to repay that.
Technical debt is not corporate debt but it is debt. The metaphor succeeds mostly because it's accurate.
Re: Technical debt is not debt; it’s not even technical
#10A) big part of the article is about the fact that the current tribal meaning of the term deviated from the meaning that the first person to use it had. This is somewhat of a semantics argument, like "hey you're using that in a commonly accepted way but Ward C didn't mean that so you're wrong".
B) article points that you're accumulating debt to get speed to market or because of incomplete knowledge of the market at some point and uses this to say "it's not technical because it's business". But it is technical because, well, it is issues with your technology. That you borrowed on your tech stack for business reasons doesn't make it less technical
C) ironically I'm arguing on semantics because I find the title to be semantically wrong. In fact I largely agree with the point of view, tech debt is the result of a strategy, be it that you want speed or low cost. Sometimes it makes sense for the business, and as long as the strategy is conscious and explained, and that we're clear with the consequences, I'm fine with it. In my experience most of the time it's not an assumed strategy and we dont want to deal with the consequences.