5 ms·

The problem here is the mischaracterization of what technical debt is. Most of the time I hear programmers talk about technical debt, what they really mean is

The problem here is the mischaracterization of what technical debt is. Most of the time I hear programmers talk about technical debt, what they really mean is profiling and performance (because over time requirements change and code size increases) or code "cleanup" which is usually a catch-all for "not how I would have done it". Performance issues are real, but those should just be scheduled and tackled as needed. Code cleanup is quite often a red herring. But technical debt is entirely different. It's exactly what the name implies: debt. We would have done X to implement a given feature or customer request, because there are many conditions and other systems to take into account. But there wasn't time to do it that way before the required deadline, so we did something else instead that would get by for now, but we all know won't last. That is technical debt. Sadly, often times management just see the issue as done on the schedule and there should therefore be no need to go back and "do it again". Always pay down technical debt when you can. It will be paid eventually, it's just a question of how painful it will be when you do.

tome 7y ago
Yes, it's extremely strange that people are looking for new terminology because they've been using the existing, perfectly good, terminology incorrectly.
TeMPOraL 7y ago
How's that meaningfully different than performance and code cleanup cases? Frequently, a team know how to implement a feature in an efficient manner, but only has time for a low-performance hack job. Similarly, "code cleanup" is as much a code word for "not how I would have done it" as it is for "bad architecture that will start constraining us very soon".
- massung 7y ago
  Performance work is no different than new features: requirements change. Code cleanup can mean many things. When talking about architecture, it could be a legit argument that due to requirement changes there needs to be a rethink. But that's not debt. That wasn't a conscious decision made in the past to do A instead of B knowing that B was the right choice, but not realistic at the moment. When talking about large code bases that have been around, code cleanup is a young person's term that tends to imply they are smarter or know more than the previous set of programmers who worked on it. That's possible, but a bad argument. And it's insulting. Obviously the code has worked for quite a while successfully, so it can't be as bad as it's being made it to be (that's management playing devil's advocate). If it hasn't been working, the schedule should reflect fixing it. Maybe that requires a massive recoding, but maybe not.
  - TeMPOraL 7y ago
    > That wasn't a conscious decision made in the past to do A instead of B knowing that B was the right choice, but not realistic at the moment. I'm thinking of cases where it was a conscious choice. $deity knows that I've made plenty of such decisions in my career - chosing a hacky structure A to meet a next month's release, while articulating to management that after that release, I'll need to redo it to structure B. Sometimes a bunch of high-priority requests took precedence, which made the system stick to A for far longer than it should. I understand that to qualify as both "technical debt" and "architectural issue".
    - alacombe 7y ago
      I'm confident that each and every one of us (even in the open-source world) can say "been there, done that".
  - closeparen 7y ago
    Cleanup is not about how the code works at runtime, but how well it supports change. An abstraction that looked right at the time shows its cracks years later. Changes that should be simple and low-risk become intense and scary when they need to fit in with it. It's not insulting. For one thing, the person proposing the change may very well be the original author. For another, you have the benefit of hindsight and access to information they didn't about what bugs would emerge, which features would be demanded, and how hard it would be to implement them. Of course you're going to see better ways of doing things than were visible on day 0. Increasing speed and reducing risk for all future iteration is some of the highest impact work you can do; rather than shipping a single feature, you're a force multiplier for all the features developed by your team. The only time it makes sense to skip cleanup is when you're content to just let the thing run, and don't see any changes in the pipeline.
    - jyounker 7y ago
      > Cleanup is not about how the code works at runtime, but how well it supports change. This. A thousand times, this.
  - 7y ago
- alacombe 7y ago
  Because "performance" is not related to "functionality". If you skip corners (eg. panic instead properly forwarding an error, hack a new implementation over an existing interface, etc), you induce a long term cost each time you have to figure out why the code is misbehaving. Technical debt is all these architectural issues which incurs a long term cost because minimum deliverables had to be met. Also, the first response to "performance" is always gonna be "throw more CPU/memory", not "let spend a month dev-time to rearchitecture." Tech-debt is only getting addressed when hardware can't meet the requirement, "performance" is just a marketing argument to sell it to management.
- bradleyjg 7y ago
  Making code perform more efficient is easily analyzed as a feature. If the inefficiency results in end user delays then it can be directly traded-off against other feature requests, if it only impacts costs it can be fairly easily be determined whether or not it is worth devoting (very expensive) developer resources against. Prioritizing improving performance for aesthetic reasons, that is because a "low-performance hack job" offends someone's sensibilities, likely means either: 1) the team is poorly lead or 2) doesn't have enough high value work to do.
philwelch 7y ago
I’m dubious of defining technical debt merely as the result of previous decisions taken to trade off delivery time for maintainability. That’s the responsible form of technical debt and responsible people will incur it. But there are irresponsible forms of technical debt just as there are irresponsible forms of financial debt. What makes something technical debt is the “interest” in terms of maintainability that one pays for it.
yarg 7y ago
I think that may companies need a fundamental shift in managerial culture before they take technical debt even remotely seriously. The only way I've ever managed to do anything about technical debt was by hiding the fact that I was doing it - since it was completely impossible to get any level of managerial buy in or even permission. It shouldn't have had to be that way, I should've had higher level support, other developers to work with and competent testers - working in that situation ultimately left me never wanting to write software for anyone else ever again. It's a disease of reckless incompetence, and it permeates the managerial structures of large swathes of the software development industry.
- artsyca 7y ago
  Same here, I'd always pay off a little debt here and there and the busy-waiters would be circling my desk asking for status -- from the busy body product owners to the nitpicking directors at their weekly inquisitions, there's a whole class of parasites whose only contribution is to trumpet how late we are and insist on asking 'how long will this take?'
  - yarg 7y ago
    I got it too the point where the standard changes took a fraction of the time to implement compared to what it would've been operating on the initial code base. In fact, some of the functionality that I ultimately implemented would not simply have taken longer, it would have been impossible to implement without introducing world ending bugs. None of that mattered. Nothing that I ever said or did in that place meant a fucking thing to anyone.
    - artsyca 7y ago
      Where have you been all my life bro! Nobody gets it any more -- precisely the attitude needed in this industry; we need to turn the tables and take our craft back in-house
dnh44 7y ago
To make the term more useful to me I like to extend the analogy and think in terms of interest paid on technical debt. So you took a shortcut because of pressure to ship but now you’re spending loads more time providing tech support. That’s the interest you’re paying on the technical debt. So in terms of choosing what technical debt to pay off first consider which ones have the highest interest payments. And remember that like financial debt, technical debt also sometimes comes with introductory interest free periods.
isostatic 7y ago
> Always pay down technical debt when you can. It will be paid eventually, it's just a question of how painful it will be when you do. Not really I have a program which is a right pain, and takes an hour to do a yearly task. To clean it up would take about 200 hours. The program is unlikely to be around in 20 years time, let alone 200.
gfody 7y ago
Your third example is just some combination of the first two. Performance issues: the efficient solution is too complex, we don't have time. Code cleanup: this is not the way I would've done it if I had more time. The debt metaphor fits so well because you're borrowing time.
regularfry 7y ago
Debt can also be taken on accidentally. You can build a couple of features one way and expect future features to be similar, but then reality bites and the way you've built them makes the next feature that happens to come along harder, and the next, and the next. Or the way you've built them doesn't allow for the rate of change in that area - something in code wants to be in config, or something in config wants to be in a CMS. In the debt analogy, it's like having a variable interest rate: you can make a decision which is correct for today's conditions, but the market moves and you're paying twice the interest and suddenly it doesn't make sense any more.

tome 7y ago

Yes, it's extremely strange that people are looking for new terminology because they've been using the existing, perfectly good, terminology incorrectly.

TeMPOraL 7y ago

How's that meaningfully different than performance and code cleanup cases? Frequently, a team know how to implement a feature in an efficient manner, but only has time for a low-performance hack job. Similarly, "code cleanup" is as much a code word for "not how I would have done it" as it is for "bad architecture that will start constraining us very soon".

massung 7y ago
Performance work is no different than new features: requirements change. Code cleanup can mean many things. When talking about architecture, it could be a legit argument that due to requirement changes there needs to be a rethink. But that's not debt. That wasn't a conscious decision made in the past to do A instead of B knowing that B was the right choice, but not realistic at the moment. When talking about large code bases that have been around, code cleanup is a young person's term that tends to imply they are smarter or know more than the previous set of programmers who worked on it. That's possible, but a bad argument. And it's insulting. Obviously the code has worked for quite a while successfully, so it can't be as bad as it's being made it to be (that's management playing devil's advocate). If it hasn't been working, the schedule should reflect fixing it. Maybe that requires a massive recoding, but maybe not.
- TeMPOraL 7y ago
  > That wasn't a conscious decision made in the past to do A instead of B knowing that B was the right choice, but not realistic at the moment. I'm thinking of cases where it was a conscious choice. $deity knows that I've made plenty of such decisions in my career - chosing a hacky structure A to meet a next month's release, while articulating to management that after that release, I'll need to redo it to structure B. Sometimes a bunch of high-priority requests took precedence, which made the system stick to A for far longer than it should. I understand that to qualify as both "technical debt" and "architectural issue".
  - alacombe 7y ago
    I'm confident that each and every one of us (even in the open-source world) can say "been there, done that".
- closeparen 7y ago
  Cleanup is not about how the code works at runtime, but how well it supports change. An abstraction that looked right at the time shows its cracks years later. Changes that should be simple and low-risk become intense and scary when they need to fit in with it. It's not insulting. For one thing, the person proposing the change may very well be the original author. For another, you have the benefit of hindsight and access to information they didn't about what bugs would emerge, which features would be demanded, and how hard it would be to implement them. Of course you're going to see better ways of doing things than were visible on day 0. Increasing speed and reducing risk for all future iteration is some of the highest impact work you can do; rather than shipping a single feature, you're a force multiplier for all the features developed by your team. The only time it makes sense to skip cleanup is when you're content to just let the thing run, and don't see any changes in the pipeline.
  - jyounker 7y ago
    > Cleanup is not about how the code works at runtime, but how well it supports change. This. A thousand times, this.
- 7y ago
alacombe 7y ago
Because "performance" is not related to "functionality". If you skip corners (eg. panic instead properly forwarding an error, hack a new implementation over an existing interface, etc), you induce a long term cost each time you have to figure out why the code is misbehaving. Technical debt is all these architectural issues which incurs a long term cost because minimum deliverables had to be met. Also, the first response to "performance" is always gonna be "throw more CPU/memory", not "let spend a month dev-time to rearchitecture." Tech-debt is only getting addressed when hardware can't meet the requirement, "performance" is just a marketing argument to sell it to management.
bradleyjg 7y ago
Making code perform more efficient is easily analyzed as a feature. If the inefficiency results in end user delays then it can be directly traded-off against other feature requests, if it only impacts costs it can be fairly easily be determined whether or not it is worth devoting (very expensive) developer resources against. Prioritizing improving performance for aesthetic reasons, that is because a "low-performance hack job" offends someone's sensibilities, likely means either: 1) the team is poorly lead or 2) doesn't have enough high value work to do.

philwelch 7y ago

I’m dubious of defining technical debt merely as the result of previous decisions taken to trade off delivery time for maintainability. That’s the responsible form of technical debt and responsible people will incur it. But there are irresponsible forms of technical debt just as there are irresponsible forms of financial debt. What makes something technical debt is the “interest” in terms of maintainability that one pays for it.

yarg 7y ago

I think that may companies need a fundamental shift in managerial culture before they take technical debt even remotely seriously. The only way I've ever managed to do anything about technical debt was by hiding the fact that I was doing it - since it was completely impossible to get any level of managerial buy in or even permission. It shouldn't have had to be that way, I should've had higher level support, other developers to work with and competent testers - working in that situation ultimately left me never wanting to write software for anyone else ever again. It's a disease of reckless incompetence, and it permeates the managerial structures of large swathes of the software development industry.

artsyca 7y ago
Same here, I'd always pay off a little debt here and there and the busy-waiters would be circling my desk asking for status -- from the busy body product owners to the nitpicking directors at their weekly inquisitions, there's a whole class of parasites whose only contribution is to trumpet how late we are and insist on asking 'how long will this take?'
- yarg 7y ago
  I got it too the point where the standard changes took a fraction of the time to implement compared to what it would've been operating on the initial code base. In fact, some of the functionality that I ultimately implemented would not simply have taken longer, it would have been impossible to implement without introducing world ending bugs. None of that mattered. Nothing that I ever said or did in that place meant a fucking thing to anyone.
  - artsyca 7y ago
    Where have you been all my life bro! Nobody gets it any more -- precisely the attitude needed in this industry; we need to turn the tables and take our craft back in-house

dnh44 7y ago

To make the term more useful to me I like to extend the analogy and think in terms of interest paid on technical debt. So you took a shortcut because of pressure to ship but now you’re spending loads more time providing tech support. That’s the interest you’re paying on the technical debt. So in terms of choosing what technical debt to pay off first consider which ones have the highest interest payments. And remember that like financial debt, technical debt also sometimes comes with introductory interest free periods.

isostatic 7y ago

> Always pay down technical debt when you can. It will be paid eventually, it's just a question of how painful it will be when you do. Not really I have a program which is a right pain, and takes an hour to do a yearly task. To clean it up would take about 200 hours. The program is unlikely to be around in 20 years time, let alone 200.

gfody 7y ago

Your third example is just some combination of the first two. Performance issues: the efficient solution is too complex, we don't have time. Code cleanup: this is not the way I would've done it if I had more time. The debt metaphor fits so well because you're borrowing time.

regularfry 7y ago

Debt can also be taken on accidentally. You can build a couple of features one way and expect future features to be similar, but then reality bites and the way you've built them makes the next feature that happens to come along harder, and the next, and the next. Or the way you've built them doesn't allow for the rate of change in that area - something in code wants to be in config, or something in config wants to be in a CMS. In the debt analogy, it's like having a variable interest rate: you can make a decision which is correct for today's conditions, but the market moves and you're paying twice the interest and suddenly it doesn't make sense any more.