3 ms·

Having bad code is not technical debt, I've seen it used that way but it's wrong, since there was no debt accrued, you just wasted all your money in Vegas. It w

Having bad code is not technical debt, I've seen it used that way but it's wrong, since there was no debt accrued, you just wasted all your money in Vegas. It was a bad decision but not "debt". The analogy doesn't work in that case. Bad code is something that happens, even to good devs. Sometimes you just don't have a clear picture of the problem and cobble something together to try and learn how to approach it. That code will be bad, but it was useful for its purpose. It only becomes debt when faced with the results of your past mistakes you choose short term gains over long term profit, i.e. you know the code is shit but you keep building on it instead of dedicating time to refactor things because you need a feature yesterday instead of tomorrow. Often this last decision comes from management, not the engineer that figure out things aren't going well.

louwrentius 5y ago
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.

louwrentius 5y ago

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.