3 ms·

> The article links tech debt to financial debt early on, and this is exactly what the analogy is - it is best to be as literal as possible about it. Financial

> The article links tech debt to financial debt early on, and this is exactly what the analogy is - it is best to be as literal as possible about it. Financial debt has a clear quantitative measure. Tech Debt is an incredibly fuzzy concept, even as a qualitative measure, to the point of being useless for anything other than covering one's ass. We can do better as engineers than resting on such fuzzy thinking.

deleted 7y ago
[deleted]
skybrian 7y ago
Yes, it's a nebulous metaphor. Taking it too seriously is a mistake. But I'm not sure we can do much better? What would you suggest? I like the Go concept of aji [1] but that's too obscure, nobody will get it. Maybe something like "unfinished business" would work? A nebulous term for a nebulous concept. [1] https://senseis.xmp.net/?Aji https://senseis.xmp.net/?Aji
- wellpast 7y ago
  What I suggest is you try to run a project and deliberately avoid reaching for the concept of "Technical Debt". You will find yourself squirming a little. It will be uncomfortable at first. But if you hold to your guns, you will find that you're forced to speak in much more clear terms about your process and decision-making. And you will certainly find yourself saying humble things like "I have a sense that this isn't the best solution, but it's all I got right now." But over time you'll find yourself improving. You'll find yourself saying "I have a sense that this isn't the best solution -- oh, you know what I just realized, this design choice is going make this other requirement over here nearly impossible to implement." And with this kind of clarity you'll be in a much much better position to navigate the territory ahead and make clear, conscious decisions based on what you know and don't know. "Tech Debt" is simply a way to dodge -- e.g., dodge the discomfort of not knowing stuff, of holding yourself to clear thinking, of admitting the need to improve...
aeorgnoieang 7y ago
I'm curious what you think is better. Any links you could share? I suspect you're wrong, or not quite right, tho. Technical debt is a great analogy and even if it's fuzzy, being able to think about the relevant tradeoffs in a familiar way is too useful to ignore. Surely there are situations in which it's only useful to cover one's ass, but often it's a great way of explicitly understanding specific tradeoffs being made.
- wellpast 7y ago
  At any given crossroads in a business endeavor, you encounter a problem. Now you have two choices: 1) You select and articulate your assumptions. You select and articulate your requirements. You also may try to capture and articulate your Black Swan list of unknowns and risks. The key thing is that you are clear. Clear what you know and clear about your concerns and risks. You then articulate your solution, holding it accountable to your assumptions, requirements. And then you move forward. - or - 2) You come up with some solution sketch. You have a general vague notion that it isn't ideal. You're not sure why but it just doesn't feel right. You need a way to psychologically contend with this vagueness. So you give the vagueness a name. The first thought that comes to your head is: "Vague Notion That This Design is Not Very Good". This is not very flattering to your ego. So you think a little bit more and come up with: "Tech Debt". And you like this, because it sounds quite nice. It sounds like you're back in control, that you know what you're doing. You proceed to blame the design deficiencies over time to "Tech Debt". Everyone nods their heads.
  - bb611 7y ago
    I work on a product with a large amount of tech debt, and that debt was almost universally created using the methodology in your first category. Most of it is extremely well documented. That doesn't magically make it not technical debt.
    - wellpast 7y ago
      Debt implies you consciously accepted it. What you’re describing with your product is the fruit of unskilled (amateur) labor.

deleted 7y ago

[deleted]

skybrian 7y ago

Yes, it's a nebulous metaphor. Taking it too seriously is a mistake. But I'm not sure we can do much better? What would you suggest? I like the Go concept of aji [1] but that's too obscure, nobody will get it. Maybe something like "unfinished business" would work? A nebulous term for a nebulous concept. [1] https://senseis.xmp.net/?Aji https://senseis.xmp.net/?Aji

wellpast 7y ago
What I suggest is you try to run a project and deliberately avoid reaching for the concept of "Technical Debt". You will find yourself squirming a little. It will be uncomfortable at first. But if you hold to your guns, you will find that you're forced to speak in much more clear terms about your process and decision-making. And you will certainly find yourself saying humble things like "I have a sense that this isn't the best solution, but it's all I got right now." But over time you'll find yourself improving. You'll find yourself saying "I have a sense that this isn't the best solution -- oh, you know what I just realized, this design choice is going make this other requirement over here nearly impossible to implement." And with this kind of clarity you'll be in a much much better position to navigate the territory ahead and make clear, conscious decisions based on what you know and don't know. "Tech Debt" is simply a way to dodge -- e.g., dodge the discomfort of not knowing stuff, of holding yourself to clear thinking, of admitting the need to improve...

aeorgnoieang 7y ago

I'm curious what you think is better. Any links you could share? I suspect you're wrong, or not quite right, tho. Technical debt is a great analogy and even if it's fuzzy, being able to think about the relevant tradeoffs in a familiar way is too useful to ignore. Surely there are situations in which it's only useful to cover one's ass, but often it's a great way of explicitly understanding specific tradeoffs being made.

wellpast 7y ago
At any given crossroads in a business endeavor, you encounter a problem. Now you have two choices: 1) You select and articulate your assumptions. You select and articulate your requirements. You also may try to capture and articulate your Black Swan list of unknowns and risks. The key thing is that you are clear. Clear what you know and clear about your concerns and risks. You then articulate your solution, holding it accountable to your assumptions, requirements. And then you move forward. - or - 2) You come up with some solution sketch. You have a general vague notion that it isn't ideal. You're not sure why but it just doesn't feel right. You need a way to psychologically contend with this vagueness. So you give the vagueness a name. The first thought that comes to your head is: "Vague Notion That This Design is Not Very Good". This is not very flattering to your ego. So you think a little bit more and come up with: "Tech Debt". And you like this, because it sounds quite nice. It sounds like you're back in control, that you know what you're doing. You proceed to blame the design deficiencies over time to "Tech Debt". Everyone nods their heads.
- bb611 7y ago
  I work on a product with a large amount of tech debt, and that debt was almost universally created using the methodology in your first category. Most of it is extremely well documented. That doesn't magically make it not technical debt.
  - wellpast 7y ago
    Debt implies you consciously accepted it. What you’re describing with your product is the fruit of unskilled (amateur) labor.