8 ms·

Technical Debt Is a Myth

26 points by gcoleman 4y ago

xupybd 4y ago
"Taking out an organisational mortgage should be a deliberate choices. It has costs, interest, pros, and cons." I could not agree more.
- PaulHoule 4y ago
  It seems like they are trying to do otherwise but I see this article as perpetuating the basic problem with "technical debt" which is the analogy with debt. But what do you expect from an article on Medium? If you take on debt the bank is going to question if you can pay it. You're going to have to go through a formal process and bring in expensive experts such as accountants to justify that taking on debt is worthwhile. Most "technical debt" is blundered into out of ignorance. Nobody sits down and thinks "we can save two hours now at the cost of three hours later" because it would probably take four hours to do the calculation. Sometimes it really is like that but frequently it is like "we can save two hours now at the cost of of two months later", such as when people make an incorrect database design that involves cleaning up corrupt data later on. Cases like that dominate the cost of "technical debt" to the point where the 2 hours now, 3 hours later cases just don't matter.
  - wizofaus 4y ago
    > Nobody sits down and thinks "we can save two hours now at the cost of three hours later" Perhaps not, but there're plenty of times you realise the "proper" solution that's going to leave you with well-structured code that's easy to maintain and easy to extend to likely future functionality is going to take weeks, whereas a quick'n'dirty solution that will get a bug fixed or an MVP-version of a feature implemented could be done in a few hours, and the latter option makes sense even from a technical POV because there's little certainty that the extra effort will pay off (esp. if it involves higher risk of breaking existing functionality, which is often the case). Unfortunately it's the accumulation of such decisions and lack of time to go back and revise decisions/rewrite code that lead to unwieldy and bug-ridden codebases.
  - yunwal 4y ago
    Isn’t the point of using the phrase “technical debt” that you should be doing this? It’s an idealistic phrase, not one that’s supposed to apply to every organization.
    - PaulHoule 4y ago
      I rarely hear "technical debt" in the context of "let's incur some technical debt now so we can deliver this ticket quickly", it's rather "we can't deliver this ticket quickly now because somebody (usually somebody else) incurred technical debt" in the past. If management is using it usually an attempt to shut discussion down in the context of (i) poor psychological safety on the part of devs because (ii) management doesn't trust anything the devs say because (iii) management knows that the devs are reading cargo-cult blog posts like "if this software was written in Haskell it wouldn't have any bugs".
      - xupybd 4y ago
        We do that. If we have to take a short cut we sit down with management and try to see if it's worth it. We need to launch so we will do this now. We know January is going to be quiet so we plan to fix it then.
    - svnt 4y ago
      It applies to every organization. You have to take some of it on unless you turn minerals into revenue using only processes and systems that can be recreated from scratch at will irrespective of who your employees are. Since no one can do that, everyone has it. Taking it on unnecessarily is bad for the health of the business and worse than financial debt because technical debt, unlike financial debt, is not fungible.
      - yunwal 4y ago
        Right, but what I mean is, not every organization out there is actually modeling their tech debt as debt. If you're using the word "tech debt" without doing calculations like "what interest am I paying on this?" or "what's my per-sprint payment if I want to fix this over the next 2 months", then you are using the phrase wrong. It's just a TODO at that point
  - postalrat 4y ago
iLoveOncall 4y ago
I'm not sure what what to think of the article because I think the definition he chose for technical debt is extremely reductive. No, technical debt does not only come from taking shortcuts. I would even go as far as saying that most of the time it does not come from taking shortcuts. - You wrote a perfectly engineered system in Cobold 30 years ago that was state of the art then? Well, now all your Cobold developers have retired and you need to add new features to that tool. It's tech debt. - Your tool was built to support 100 users but now it needs to support 100M? It's tech debt. - You were getting some data from the Google Stadia API? Tech debt. - You're using a library that just got an important security update? Tech debt. As another commenter pointed out, the term "debt" was wrongly chosen. It's not debt. It's stuff that used to be perfectly fine and due to no fault of yours is not anymore.
- pixl97 4y ago
  Technical entropy. Entropy is unavoidable is the outcome of any work occurring.
  - svnt 4y ago
    It’s a cool-sounding term. I think I agree if things are viewed zoomed out enough (temporally), but isn’t the issue actually (unknown, outdated) structure, not entropy? The entropy is what comes about as the old structure gives way.
- svnt 4y ago
  > It's not debt. It's stuff that used to be perfectly fine and due to no fault of yours is not anymore. The risk of this happening is more or less measurable and is the debt. Denying responsibility doesn’t make the debt not exist. It might mean you’re so far removed from understanding how your (sub)systems function that you’re unable to assess it. It may be so complex that no one is able to quantify it, in which case I suppose “it doesn’t exist” might be accurate enough — either your business fails or it doesn’t based on the success of your subsystems, and your business outcome is the measurement. I’d rather have someone else be the measurement.
tqi 4y ago
> When we use the term technical debt, lots of non-technical people hear, ‘This is a technical problem, with technical solutions.’ This thinking couldn’t be further from the truth. If the organisation is responsible for the creation of the debt (as established above), it’s also responsible for the elimination of it. Debt belongs to the entire organisation. This is a strawman.
- karmakaze 4y ago
  [Up to the expected quality of a Medium post.] It renames Tech Debt as an "organisational mortgage—a loan the business takes out against future capabilities to deliver, which has to be paid back with interest. In this way, it’s no different than any other loan, or any other debt the organisation incurs." The difference of course is that this debt has a technical solution, as opposed to a financial one.
  - xupybd 4y ago
    Using resources to implement a technical solution is a financial cost. Some technical debt is from poor planning and design. Some is from a choice to get things done now that are quicker and cheaper but will cause some pain in the future. In that way technical debt is different, but it still has a cost to solve.
NoPicklez 4y ago
I feel like the author just slightly reframed the term technical debt to being abount a mortgage and that's the article.
- xupybd 4y ago
  The article doesn't say a lot, I agree with you there. But I like this part "should be a deliberate choices. It has costs, interest, pros, and cons." Any "Technical debt" that is not a deliberate choice fails to fit the analogy. Often it's just crappy design or implementation. There are times that you need to take on some debt to move forward because you don't have the resources to do it otherwise. That to me is where the analogy works well and the important part is to make sure management is making that call not some overworked developer.

26 points by gcoleman 4y ago

"Taking out an organisational mortgage should be a deliberate choices. It has costs, interest, pros, and cons." I could not agree more.

PaulHoule 4y ago
It seems like they are trying to do otherwise but I see this article as perpetuating the basic problem with "technical debt" which is the analogy with debt. But what do you expect from an article on Medium? If you take on debt the bank is going to question if you can pay it. You're going to have to go through a formal process and bring in expensive experts such as accountants to justify that taking on debt is worthwhile. Most "technical debt" is blundered into out of ignorance. Nobody sits down and thinks "we can save two hours now at the cost of three hours later" because it would probably take four hours to do the calculation. Sometimes it really is like that but frequently it is like "we can save two hours now at the cost of of two months later", such as when people make an incorrect database design that involves cleaning up corrupt data later on. Cases like that dominate the cost of "technical debt" to the point where the 2 hours now, 3 hours later cases just don't matter.
- wizofaus 4y ago
  > Nobody sits down and thinks "we can save two hours now at the cost of three hours later" Perhaps not, but there're plenty of times you realise the "proper" solution that's going to leave you with well-structured code that's easy to maintain and easy to extend to likely future functionality is going to take weeks, whereas a quick'n'dirty solution that will get a bug fixed or an MVP-version of a feature implemented could be done in a few hours, and the latter option makes sense even from a technical POV because there's little certainty that the extra effort will pay off (esp. if it involves higher risk of breaking existing functionality, which is often the case). Unfortunately it's the accumulation of such decisions and lack of time to go back and revise decisions/rewrite code that lead to unwieldy and bug-ridden codebases.
- yunwal 4y ago
  Isn’t the point of using the phrase “technical debt” that you should be doing this? It’s an idealistic phrase, not one that’s supposed to apply to every organization.
  - PaulHoule 4y ago
    I rarely hear "technical debt" in the context of "let's incur some technical debt now so we can deliver this ticket quickly", it's rather "we can't deliver this ticket quickly now because somebody (usually somebody else) incurred technical debt" in the past. If management is using it usually an attempt to shut discussion down in the context of (i) poor psychological safety on the part of devs because (ii) management doesn't trust anything the devs say because (iii) management knows that the devs are reading cargo-cult blog posts like "if this software was written in Haskell it wouldn't have any bugs".
    - xupybd 4y ago
      We do that. If we have to take a short cut we sit down with management and try to see if it's worth it. We need to launch so we will do this now. We know January is going to be quiet so we plan to fix it then.
  - svnt 4y ago
    It applies to every organization. You have to take some of it on unless you turn minerals into revenue using only processes and systems that can be recreated from scratch at will irrespective of who your employees are. Since no one can do that, everyone has it. Taking it on unnecessarily is bad for the health of the business and worse than financial debt because technical debt, unlike financial debt, is not fungible.
    - yunwal 4y ago
      Right, but what I mean is, not every organization out there is actually modeling their tech debt as debt. If you're using the word "tech debt" without doing calculations like "what interest am I paying on this?" or "what's my per-sprint payment if I want to fix this over the next 2 months", then you are using the phrase wrong. It's just a TODO at that point
- postalrat 4y ago

iLoveOncall 4y ago

I'm not sure what what to think of the article because I think the definition he chose for technical debt is extremely reductive. No, technical debt does not only come from taking shortcuts. I would even go as far as saying that most of the time it does not come from taking shortcuts. - You wrote a perfectly engineered system in Cobold 30 years ago that was state of the art then? Well, now all your Cobold developers have retired and you need to add new features to that tool. It's tech debt. - Your tool was built to support 100 users but now it needs to support 100M? It's tech debt. - You were getting some data from the Google Stadia API? Tech debt. - You're using a library that just got an important security update? Tech debt. As another commenter pointed out, the term "debt" was wrongly chosen. It's not debt. It's stuff that used to be perfectly fine and due to no fault of yours is not anymore.

pixl97 4y ago
Technical entropy. Entropy is unavoidable is the outcome of any work occurring.
- svnt 4y ago
  It’s a cool-sounding term. I think I agree if things are viewed zoomed out enough (temporally), but isn’t the issue actually (unknown, outdated) structure, not entropy? The entropy is what comes about as the old structure gives way.
svnt 4y ago
> It's not debt. It's stuff that used to be perfectly fine and due to no fault of yours is not anymore. The risk of this happening is more or less measurable and is the debt. Denying responsibility doesn’t make the debt not exist. It might mean you’re so far removed from understanding how your (sub)systems function that you’re unable to assess it. It may be so complex that no one is able to quantify it, in which case I suppose “it doesn’t exist” might be accurate enough — either your business fails or it doesn’t based on the success of your subsystems, and your business outcome is the measurement. I’d rather have someone else be the measurement.

tqi 4y ago

> When we use the term technical debt, lots of non-technical people hear, ‘This is a technical problem, with technical solutions.’ This thinking couldn’t be further from the truth. If the organisation is responsible for the creation of the debt (as established above), it’s also responsible for the elimination of it. Debt belongs to the entire organisation. This is a strawman.

karmakaze 4y ago
[Up to the expected quality of a Medium post.] It renames Tech Debt as an "organisational mortgage—a loan the business takes out against future capabilities to deliver, which has to be paid back with interest. In this way, it’s no different than any other loan, or any other debt the organisation incurs." The difference of course is that this debt has a technical solution, as opposed to a financial one.
- xupybd 4y ago
  Using resources to implement a technical solution is a financial cost. Some technical debt is from poor planning and design. Some is from a choice to get things done now that are quicker and cheaper but will cause some pain in the future. In that way technical debt is different, but it still has a cost to solve.

NoPicklez 4y ago

I feel like the author just slightly reframed the term technical debt to being abount a mortgage and that's the article.

xupybd 4y ago
The article doesn't say a lot, I agree with you there. But I like this part "should be a deliberate choices. It has costs, interest, pros, and cons." Any "Technical debt" that is not a deliberate choice fails to fit the analogy. Often it's just crappy design or implementation. There are times that you need to take on some debt to move forward because you don't have the resources to do it otherwise. That to me is where the analogy works well and the important part is to make sure management is making that call not some overworked developer.