4 ms·

This is NOT the definition of TD as Ward Cunningham described it. It was never about trading short-term goals for long-term slowdowns. It was about building so

This is NOT the definition of TD as Ward Cunningham described it. It was never about trading short-term goals for long-term slowdowns. It was about building software with the specific goal as to learn about the problem domain and the concepts. It is focused on high-level architecture, understanding and discovering the foundational structure. And once you gain new insights NOT reworking code to align with new insights would result in ‘real’ technical debt.

sirwhinesalot 5y ago
I'm not concerned with Ward Cunningham's original description. Keeping the prototype that was used to learn about the problem as the actual solution to the problem (without refactoring according to the new insights) is most certainly trading short-term goals for long-term slowdowns and a common occurrence. There's no such thing as a prototype in practice, unfortunately from my experience. If management sees something half working then they don't want to toss it out. These days the concept of technical debt has simply expanded to all other situations where this tradeoff occurs, where the knowledge is already partially there but the decision to go with the "prototype" (which is not a prototype because it's already known to be a dead end) is still made. TL;DR: Tech debt occurs any time you write throwaway code to achieve some short term result, which you don't clean up later (pay the debt). Ward Cunningham's original definition is an instance of this more general definition, his is unnecessarily specific IMO.
- louwrentius 5y ago
  I think you read the wrong intentions in Wards definition. It was never about short-term goals. It was about building something to gain understanding of the problem space and deliberately taking the time to incorporate new insights into the code. Not doing so would make adding functionality more difficult long-term. 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. Your definition of technical debt is just making trade-offs and that just is that: explaining the actual trade-off and there is no need to talk about technical debt. It’s just a bullshit empty label.
  - sirwhinesalot 5y ago
    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 :)

sirwhinesalot 5y ago

I'm not concerned with Ward Cunningham's original description. Keeping the prototype that was used to learn about the problem as the actual solution to the problem (without refactoring according to the new insights) is most certainly trading short-term goals for long-term slowdowns and a common occurrence. There's no such thing as a prototype in practice, unfortunately from my experience. If management sees something half working then they don't want to toss it out. These days the concept of technical debt has simply expanded to all other situations where this tradeoff occurs, where the knowledge is already partially there but the decision to go with the "prototype" (which is not a prototype because it's already known to be a dead end) is still made. TL;DR: Tech debt occurs any time you write throwaway code to achieve some short term result, which you don't clean up later (pay the debt). Ward Cunningham's original definition is an instance of this more general definition, his is unnecessarily specific IMO.

louwrentius 5y ago
I think you read the wrong intentions in Wards definition. It was never about short-term goals. It was about building something to gain understanding of the problem space and deliberately taking the time to incorporate new insights into the code. Not doing so would make adding functionality more difficult long-term. 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. Your definition of technical debt is just making trade-offs and that just is that: explaining the actual trade-off and there is no need to talk about technical debt. It’s just a bullshit empty label.
- sirwhinesalot 5y ago
  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 :)