2 ms·

I think we'll just have to agree to disagree. Specifically about this part: > Obviously not incorporating such learning can be seen as a short-term objective,

I think we'll just have to agree to disagree. Specifically about this part: > Obviously not incorporating such learning can be seen as a short-term objective, but it is more about being actually aware that you need some time incorporating lessons learned or otherwise there are consequences. Why would someone take the time to do a learning activity and then not only ignore the results of said activity but actually deliver the knowingly bad attempt? The important part is why someone would do this, the motive. There is only one reason to do so: they don't want to spend the time and or resources, or need to spend them somewhere else. That's a trade-off of course, so technical debt always involves making a trade-off, even in Wards definition. I also vehemently disagree it is an empty label, it describes quite nicely the concern through analogy: paying interest (slowing down development) on debt (throwaway code that was kept). There are other trade-offs that are nothing like this.

louwrentius 5y ago
I understand your point perfectly, but it is only valid at the abstract level Ward defines it. However what people did is ignore his actual point and ran with the ‘debt’ analogy and now we call ‘not applying patches for a year’ technical debt whereas this is clearly just bullshit. And for more serious topic, every trade-off somehow gets called TD. Every deviation from some platonic ideal is TD. It just is extremely unhelpful for any meaningful discussion.
- sirwhinesalot 5y ago
  I see your point and I agree. The term has become too diluted. I don't have a good solution to the problem. Perhaps dropping the term is the way to go, but I'm not sure what I'd replace it by. I guess we can start saying "we have too much throwaway code left in production".
  - louwrentius 5y ago
    You just hit exactly on the right topic: I think we don’t need a replacement. Your example is perfect, just name the actual issue and deal with it. That’s frankly all I really propose in the end. Also, I think that some decisions are to be made within the development team. It is not for the business to tell them how to develop and keep the code base healthy. Some thing you just do and they are just cost of doing business. Business wants features and never wants to say, ok do maintenance tasks for a month. I’ve seen it play out, a lack of critical maintenance imposed by product caused days of expensive outages across multiple customers. Thanks for being my sounding board :)

louwrentius 5y ago

I understand your point perfectly, but it is only valid at the abstract level Ward defines it. However what people did is ignore his actual point and ran with the ‘debt’ analogy and now we call ‘not applying patches for a year’ technical debt whereas this is clearly just bullshit. And for more serious topic, every trade-off somehow gets called TD. Every deviation from some platonic ideal is TD. It just is extremely unhelpful for any meaningful discussion.

sirwhinesalot 5y ago
I see your point and I agree. The term has become too diluted. I don't have a good solution to the problem. Perhaps dropping the term is the way to go, but I'm not sure what I'd replace it by. I guess we can start saying "we have too much throwaway code left in production".
- louwrentius 5y ago
  You just hit exactly on the right topic: I think we don’t need a replacement. Your example is perfect, just name the actual issue and deal with it. That’s frankly all I really propose in the end. Also, I think that some decisions are to be made within the development team. It is not for the business to tell them how to develop and keep the code base healthy. Some thing you just do and they are just cost of doing business. Business wants features and never wants to say, ok do maintenance tasks for a month. I’ve seen it play out, a lack of critical maintenance imposed by product caused days of expensive outages across multiple customers. Thanks for being my sounding board :)