4 ms·

What I don't like about "technical debt" is that it's usually interpreted as "technical" debt: it's only a problem for the developers, the techies. You immediat

by mmcnl 3y ago

What I don't like about "technical debt" is that it's usually interpreted as "technical" debt: it's only a problem for the developers, the techies. You immediately lose the business stakeholders once you start talking about technical debt. But the problem of technical debt if a problem for everyone, not just the devs, because it is reflected in quality and time-to-market. I feel having that conversation about time-to-market and quality with business stakeholders is incredibly important and is often skipped. This in turn alienates business stakeholders from the developers, which is counter-productive. So yes, the core idea of technical debt resonates with developers, but not with business stakeholders. So if you really think the business is going to be okay with "we're gonna slow down our time-to-market and say no to all your requests for a while because we need to pay back our technical debt" (which is something I see happening over and over again), you're just keeping them out of the loop and taking over their responsibilities without actually having their accountability. Developers shouldn't decide whether time and money should be invested in time-to-market and quality or feature delivery, but that's effectively what's happening when business is not involved in the tech debt discussion. This only leads to friction and suboptimal results. That's why I think we really need to be careful when using the words "technical debt" and not just label everything we don't really understand or think can be improved as "technical debt". Challenge yourself: what really is the problem with this piece of code, other than that we don't like it?

convolvatron 3y ago
unless its a perfect shining jewel - every piece of existing code constrains future development, until progress asymptotically approaches zero and development cost asymptotically approaches infinity
- hnfong 3y ago
  > every piece of existing code constrains future development If that were literally true, then every new development would rationally necessitate a total rewrite of the codebase. You might have meant that parts of the existing codebase would need to be changed to adapt to the new development, but as long as you've made a rational decision to keep using parts of the existing codebase, it must have been a net positive otherwise you'd just throw it all away.
ska 3y ago
> So yes, the core idea of technical debt resonates with developers, but not with business stakeholders. I think that if this is the case, you are presenting it wrong. Business types are very familiar with the tradeoffs of debt financing, you have present it as being paid in effort vs. $ (which after all, have a close relationship) and they will immediately understand that a large technical debt means you can get less desired stuff done for the same input of effort. And then you collectively decide. Agree you have to be careful about what you present as technical debt. If you need buy in from the business side, you don't want them thinking "that's just what they say when they want more time, it doesn't mean anything". It has to be pretty concrete.
- mmcnl 3y ago
  I think we're largely agreeing, but a fundamental difference is that actual debt you have to pay back, and with technical debt you don't. So inherently you need to start discussing the trade-offs associated with the debt, and not the actual "debt" itself. Technical debt is not some external thing that we are forced to deal with.
djur 3y ago
In the contemporary tech industry, there's a pretty good chance that the managers who oversaw the decision to incur technical debt are not going to be the managers who make the call whether to "repay" it. It might not even be the same programmers. The "debt" metaphor makes a lot of sense when you're saying "you are asking for something that will incur a cost that we will later need to repay". It seems less effective when you're saying "your predecessor's predecessor asked my predecessor's predecessor for something that probably made sense at the time, but now we 'owe' some work on fixing the problem they left us".
- mmcnl 3y ago
  The thing with actual debt is that you have to pay it back, because you agreed to do that in a formal way. That's not the case with technical debt. No one says you have to pay it back. That's why I think the metaphor falls flat when you use it with business stakeholders.

by mmcnl 3y ago

convolvatron 3y ago

unless its a perfect shining jewel - every piece of existing code constrains future development, until progress asymptotically approaches zero and development cost asymptotically approaches infinity

hnfong 3y ago
> every piece of existing code constrains future development If that were literally true, then every new development would rationally necessitate a total rewrite of the codebase. You might have meant that parts of the existing codebase would need to be changed to adapt to the new development, but as long as you've made a rational decision to keep using parts of the existing codebase, it must have been a net positive otherwise you'd just throw it all away.

ska 3y ago

> So yes, the core idea of technical debt resonates with developers, but not with business stakeholders. I think that if this is the case, you are presenting it wrong. Business types are very familiar with the tradeoffs of debt financing, you have present it as being paid in effort vs. $ (which after all, have a close relationship) and they will immediately understand that a large technical debt means you can get less desired stuff done for the same input of effort. And then you collectively decide. Agree you have to be careful about what you present as technical debt. If you need buy in from the business side, you don't want them thinking "that's just what they say when they want more time, it doesn't mean anything". It has to be pretty concrete.

mmcnl 3y ago
I think we're largely agreeing, but a fundamental difference is that actual debt you have to pay back, and with technical debt you don't. So inherently you need to start discussing the trade-offs associated with the debt, and not the actual "debt" itself. Technical debt is not some external thing that we are forced to deal with.

djur 3y ago

In the contemporary tech industry, there's a pretty good chance that the managers who oversaw the decision to incur technical debt are not going to be the managers who make the call whether to "repay" it. It might not even be the same programmers. The "debt" metaphor makes a lot of sense when you're saying "you are asking for something that will incur a cost that we will later need to repay". It seems less effective when you're saying "your predecessor's predecessor asked my predecessor's predecessor for something that probably made sense at the time, but now we 'owe' some work on fixing the problem they left us".

mmcnl 3y ago
The thing with actual debt is that you have to pay it back, because you agreed to do that in a formal way. That's not the case with technical debt. No one says you have to pay it back. That's why I think the metaphor falls flat when you use it with business stakeholders.