3 ms·

I think you are being overly harsh. Since you seem to take issue with the term tech debt as a fuzzy term, I suggest you read up on the research on this matter (

I think you are being overly harsh. Since you seem to take issue with the term tech debt as a fuzzy term, I suggest you read up on the research on this matter (Researchers talks and paper published by https://sei.cmu.edu https://sei.cmu.edu is a good starting point). A developer aiming for technical supremacy for its own sake isn't useful in a real-world business scenario. I've seen enough technically superior software products utterly fail in the market due to poor product-market fit iteration speed. Tech debt isn't a choice an individual developer should make. Tech leaders at the top of any evolving software based product/service should deeply understand the pros and cons of the concept of tech debt and then decide to use it as a strategy lever. They will have to make appropriate choices w.r.t people and process that is right for their company to leverage tech debt. This will reflect in the technical architecture of the systems as well. There will be different layers of the stack where tech debt can be more vs less. There are automated measure that can keep you informed if the tech debt is exceeding to the point where it is becoming a net liability (vs being a net asset as a strategic lever). It may be true that many organizations use the term tech debt very fuzzily and don't really give it conscious and serious thought and put effort to structurally leverage it. In this, your rage against may be justified. For those who are interested to read more on tech debt should visit these links: https://martinfowler.com/bliki/DesignStaminaHypothesis.html https://martinfowler.com/bliki/DesignStaminaHypothesis.html https://martinfowler.com/bliki/TechnicalDebtQuadrant.html https://martinfowler.com/bliki/TechnicalDebtQuadrant.html https://2019.techdebtconf.org https://2019.techdebtconf.org

wellpast 7y ago
> Researchers talks and paper published by https://sei.cmu.edu https://sei.cmu.edu is a good starting point Please link to a real paper that explores Technical Debt. This is just the link to SEI's home page. I'm looking for clarity, not hand waves. > A developer aiming for technical supremacy for its own sake isn't useful in a real-world business scenario. You're straw-manning. We're not looking for technical supremacy at all. (See my point #2 and my emphasis on brutal practicality.) We are looking for business optimization and all of the pragmatism that comes with that. My objection is to using a dodgeball term like "Tech Debt", which in no way helps to carve a pragmatic path forward. It is akin to hand-waving. If you move forward with any degree of efficiency, it will be in spite of your use of the fuzzy notion of "Tech Debt". You can do just as well without this (non-)concept. I would call this "My Thesis" but that acts as if the burden on me is to justify my objection. The burden is on whoever introduces this silly "Tech Debt" notion to 1) clarify what exactly it means and how to measure it; and 2) give a model in which the measurement can correlate with an improvement to the software process. Otherwise you're just talking Santa Claus. I have yet to see anything close to that kind of clarity when one discusses Tech Debt. There are a dime a dozen posts on "Tech Debt" and if you dig just a little you'll see that it is nearly always used to avoid clear analysis. To be fair, clear analysis is hard, so I can understand why people give up and take the easy path. But let's call the spade a spade. "Tech Debt" is a dodge. It's not a constructive tool. Your links are not helping your case either. Fowler's writing explicitly makes a distinction between quadrants of Tech Debt and the only one he calls "Prudent" is the panic "We must ship now scenario." If this is the only form of "good" Tech Debt, then my case rests completely. Because all that is being said then is that "I literally have no idea what situation my code assets are in but I have to ship now, so let's go with whatever's on disk!" Again, this is fair business. Anything is fair business. But this is certainly a position of ignorance and not a position of strategic choice. So if can admit that "Tech Debt" is simply "Ignorance", then we are all in agreement. Admitting ignorance, incidentally, is the only way an experienced practitioner can emerge and reduce the likelihood of being in such positions to begin with. Matters are even worse. Besides "Tech Debt" being a useless concept. For the individual it creates no clarity, no admission of deficiency, and no incentive or need for growth.
- vinay_ys 7y ago
  >> The burden is on whoever introduces this silly "Tech Debt" notion to 1) clarify what exactly it means and how to measure it; and 2) give a model in which the measurement can correlate with an improvement to the software process. I would highly recommend this book: https://www.oreilly.com/library/view/managing-technical-debt/9780135646052/ https://www.oreilly.com/library/view/managing-technical-debt... Also, read the papers presented at this conference series. https://2019.techdebtconf.org/#program https://2019.techdebtconf.org/#program
  - wellpast 7y ago
    Thanks for these links. I read through the book's examples of Tech Debt. The book enumerates some examples of failed software projects and calls their failures "Tech Debt". I have two issues with this. The first is how fuzzy this still is. This term is thrown over all of these various kinds of failure. And the examples are also quite varied - most are phrased as mere symptoms of failure not root causes, which gives us little insight. The bigger problem I have is that these examples are retrospective. If Tech Debt is simply a term for "mistakes I have made", then by all means use it -- obviously in this form it has no strategic/constructive value. But the way I've seen it typically used is for people to act as if it is akin to real debt, consciously acquired. "Oh I didn't make this transactional because Tech Debt." Etc. And indeed if Tech Debt as a concept is to have any value it should be able to be used this way. But my objection is that there is no way it can be used as such, because it is far too nebulous a concept to have any navigational benefit. It gives no helpful path forward. It is purely a euphemism for mistakes. That's how I've seen it used universally, at least.

wellpast 7y ago

> Researchers talks and paper published by https://sei.cmu.edu https://sei.cmu.edu is a good starting point Please link to a real paper that explores Technical Debt. This is just the link to SEI's home page. I'm looking for clarity, not hand waves. > A developer aiming for technical supremacy for its own sake isn't useful in a real-world business scenario. You're straw-manning. We're not looking for technical supremacy at all. (See my point #2 and my emphasis on brutal practicality.) We are looking for business optimization and all of the pragmatism that comes with that. My objection is to using a dodgeball term like "Tech Debt", which in no way helps to carve a pragmatic path forward. It is akin to hand-waving. If you move forward with any degree of efficiency, it will be in spite of your use of the fuzzy notion of "Tech Debt". You can do just as well without this (non-)concept. I would call this "My Thesis" but that acts as if the burden on me is to justify my objection. The burden is on whoever introduces this silly "Tech Debt" notion to 1) clarify what exactly it means and how to measure it; and 2) give a model in which the measurement can correlate with an improvement to the software process. Otherwise you're just talking Santa Claus. I have yet to see anything close to that kind of clarity when one discusses Tech Debt. There are a dime a dozen posts on "Tech Debt" and if you dig just a little you'll see that it is nearly always used to avoid clear analysis. To be fair, clear analysis is hard, so I can understand why people give up and take the easy path. But let's call the spade a spade. "Tech Debt" is a dodge. It's not a constructive tool. Your links are not helping your case either. Fowler's writing explicitly makes a distinction between quadrants of Tech Debt and the only one he calls "Prudent" is the panic "We must ship now scenario." If this is the only form of "good" Tech Debt, then my case rests completely. Because all that is being said then is that "I literally have no idea what situation my code assets are in but I have to ship now, so let's go with whatever's on disk!" Again, this is fair business. Anything is fair business. But this is certainly a position of ignorance and not a position of strategic choice. So if can admit that "Tech Debt" is simply "Ignorance", then we are all in agreement. Admitting ignorance, incidentally, is the only way an experienced practitioner can emerge and reduce the likelihood of being in such positions to begin with. Matters are even worse. Besides "Tech Debt" being a useless concept. For the individual it creates no clarity, no admission of deficiency, and no incentive or need for growth.

vinay_ys 7y ago
>> The burden is on whoever introduces this silly "Tech Debt" notion to 1) clarify what exactly it means and how to measure it; and 2) give a model in which the measurement can correlate with an improvement to the software process. I would highly recommend this book: https://www.oreilly.com/library/view/managing-technical-debt/9780135646052/ https://www.oreilly.com/library/view/managing-technical-debt... Also, read the papers presented at this conference series. https://2019.techdebtconf.org/#program https://2019.techdebtconf.org/#program
- wellpast 7y ago
  Thanks for these links. I read through the book's examples of Tech Debt. The book enumerates some examples of failed software projects and calls their failures "Tech Debt". I have two issues with this. The first is how fuzzy this still is. This term is thrown over all of these various kinds of failure. And the examples are also quite varied - most are phrased as mere symptoms of failure not root causes, which gives us little insight. The bigger problem I have is that these examples are retrospective. If Tech Debt is simply a term for "mistakes I have made", then by all means use it -- obviously in this form it has no strategic/constructive value. But the way I've seen it typically used is for people to act as if it is akin to real debt, consciously acquired. "Oh I didn't make this transactional because Tech Debt." Etc. And indeed if Tech Debt as a concept is to have any value it should be able to be used this way. But my objection is that there is no way it can be used as such, because it is far too nebulous a concept to have any navigational benefit. It gives no helpful path forward. It is purely a euphemism for mistakes. That's how I've seen it used universally, at least.