6 ms·

Tech debt is only a useful label for communicating with non-technical people. As a concept it lacks all nuance. I argue it is one of those vague, amorphous blo

Tech debt is only a useful label for communicating with non-technical people. As a concept it lacks all nuance. I argue it is one of those vague, amorphous blobs that means anything to anyone, to the point that no one agrees on anything when discussing it, except that it exists. Everyone thinks they know what it is though, which makes it all the worse. I advocate we discuss real issues with code and architecture instead of using the term 'tech debt'. Articles like this are like going to a self-help speaker. You walk away feeling great but also totally unequipped to change anything because the advice was contrived and only works in non-existent general situations.

deleted 5y ago
[deleted]
Retric 5y ago
It’s a useful way to frame things in technical discussions. Everyone wants to refactor ugly code, but unless the team is paying interest because the code is bad it’s rarely worth it just because. Aka if it’s 5 years old and nobody had needed to edit it then yes it’s ugly but the interest rate is probably low. Meanwhile stuff that just a little off but gets touched every week can be much more meaningful.
- errantmind 5y ago
  I don't think it is at all useful in technical discussions as it anchors the discussion in backwards reasoning (deduction). Better to start with real observations about the workings of a particular piece of software or architecture, then reason about why it may have certain 'bad' properties. This more often leads to action and mutual understanding, but requires actually putting in some mental effort. In your example, calling some code 'ugly' is another example of what I'm saying not to do, it is starting at a conclusion and reasoning backwards. For an example of what I'm advocating, say you started a project and defined certain architectural principles after a series of discussions with stakeholders. Let's say one of those principles is efficiency/speed of execution because the stakeholders use the software synchronously. So, that is how you define code quality in that project. You benchmark and eliminate hotspots until you reach acceptable performance. Independent of context, fast code may appear ugly to some people, but in this context it is not, perhaps it is even beautiful as it so embodies and elevates the architectural principle it was designed around. Developers now have a frame to surface issues and everyone can agree on what an issue is, because you defined what an issue looks like and why it is important, up front, as one of your architectural principles. This is basically a context-bound value system. There is no need to even use the words 'technical debt'. In a real project you have multiple competing architectural principles but these are prioritized so you know how to evaluate whether or not something is 'good' or 'bad'. As a project leader I believe it is your job to define these architectural principles, to enable developers to frame 'good and bad' as well as to prioritize their work. I used this approach when leading a project and it was very effective.
  - Retric 5y ago
    If your code isn’t fast enough to meet spec, that’s just a defect. QA should create a ticket even if you don’t. There are however a meaningful class of issues that have zero direct impact outside the team, but are still issues for your team. The best example of that is how long it takes to setup your build environment, frankly your users have zero reason to care but it can still slow your teams progress over time. Really the cost and payoff of fixing it is simply time / a better work environment. Different teams will of course use technical debt to describe stuff outside of that context, but if it directly benefits users then it’s really something else.
- chinchilla2020 5y ago
  > ugly code Ugly code doesn't cause issues. Refactoring a reliable, functional, easily maintained codebase because it isn't elegant (or 'beautiful') is a waste of time.
  - Retric 5y ago
    I think you’re describing something else. The defining characteristic of ugly code is it’s hard to reason about and thus not easy to maintain. It can still reliable, functional, and ugly.
    - dilyevsky 5y ago
      People (myself included) usually overestimate their ability to ship more readable code that has bug-for-bug parity with complex existing codebase.
      - Spivak 5y ago
        I think step zero for this kinda thing should be writing a test suite using the current code as the reference implementation. Then you spike it out with a first pass and if your clean version can’t get 90%+ without lots of edge case handling or abstraction breaking then you keep what you have.
        dilyevsky 5y ago
        That’s exactly my point - chasing that 10% remainder will make the new thing similarly hacks-ridden as the original
      - Retric 5y ago
        I think you’re getting at a deeper issue. The need for bug-for-bug parity internally is itself a sign of technical debt. At this point we can’t for example fix historical calendars, so all highly accurate date and time related code is going to be complicated and full of edge cases. Such code is in effect an interest payment on society’s existing technical debt. So, the temptation to refactor such code is generally attacking the wrong side of a problem. The best approach may be to quarantine such code/systems and try and minimize the impact of such issues.
- mmcnl 5y ago
  What is the impact on the end user? Will anyone notice or care if you don't address the technical debt?
  - Retric 5y ago
    In the platonic ideal of technical debut it should have zero direct impact on users. Indirect impacts are a slowdown in the release of new features, and or bug fixes etc.
    - mmcnl 5y ago
      Impact is impact. Slower roll-out of future releases is already way more specific than a vague arbitrary term "technical debt", right? I challenge you to come up with a situation where technical debt is a better way to describe activities than indirect impact as you are doing here.
      - Retric 5y ago
        How about someone saying “The X has _.” For one it’s more specific. Saying the existing code has indirect impact doesn’t even define if it’s a good or bad impact. If you want to say, the existing code has long description that just means technical debt then sure they mean the same thing but the term technical debt is more concise. You can still add all the low level details, but redundancy in communication still aids clarity.
NAHWheatCracker 5y ago
Talking about "real issues" doesn't always work. A few years ago, a director at my organization said at an all-hands meeting that he viewed "tech debt is a debt we never have to pay and have no interest on". In one swoop, he told the entire organization that technology concerns are not valid. People have been complaining for years using specific issues. We could point at times that important services went down. We could point at full time operations people who have to babysit applications. We could point at failed initiatives. The bi-annual company survey always has "we're fighting the same fires" in the top issues. I suppose the issue with talking about tech debt to non-technical people is that they don't care. It doesn't affect them. At least not directly, like it does for developers.
- ma2rten 5y ago
  It sounds like that company was just dysfunctional.
  - NAHWheatCracker 5y ago
    There are good things and bad things. There is nuance. I haven't and can't provide the whole picture. I just provided one anecdote that I felt is relevant to the discussion here. In re-reading my comments, I think it's easier to interpret what I wrote in an only negative way. I think that dealing with technical debt is would be a topic that the company does poorly. On the flip side, they build new products quickly and use new tech often. I consider the organization to be similar to other big-company feature factories. There's a degree of dysfunction in that, but also has a purpose.
- mmcnl 5y ago
  If it doesn't affect the non-technical people, is it an issue then? I tend to be on the side of your director to be honest.
  - NAHWheatCracker 5y ago
    It does affect them indirectly. More importantly, it affects the company. Engineer's lose motivation and put less effort in. The company has to spend more budget on operations. Emergencies come up. Projects fail to deliver on-time. These things are the tech debt and the interest being paid. He had a point in some cases. There are products that aren't used or aren't under active development. He was lumping all of the tech debt together. He was saying to everyone in the organization that he viewed all tech debt this way.
tyingq 5y ago
I agree. It's used for things that really do feel like debt. Perhaps a dependency on a library that no longer has support. But then it's also used for subjective things like "too monolithic" or "spaghetti code" where the value of fixing might not be clear. Or even that the issue is really an issue.
mmcnl 5y ago
It doesn't mean anything. Does a defined work package improve the product you are building in any way? Then plan the work. If not, then don't do it. I discourage using this term within my team, because it's not a transparent term.
nickm12 5y ago
Embrace the ambiguity. People argue what it means for something to be a sandwich as well, and "tech debt" is just a tad more ambiguous. But as a metaphor and concept, it seems to be quite sticky and we've been talking about it for thirty years now, so I think people find it useful despite the ambiguity. I recently explained tech debt to my 17 year old son, who is very interested in programming. It was difficult to come up with a crisp definition that captured what I mean by tech debt, but it was a good conversation.

deleted 5y ago

[deleted]

Retric 5y ago

It’s a useful way to frame things in technical discussions. Everyone wants to refactor ugly code, but unless the team is paying interest because the code is bad it’s rarely worth it just because. Aka if it’s 5 years old and nobody had needed to edit it then yes it’s ugly but the interest rate is probably low. Meanwhile stuff that just a little off but gets touched every week can be much more meaningful.

errantmind 5y ago
I don't think it is at all useful in technical discussions as it anchors the discussion in backwards reasoning (deduction). Better to start with real observations about the workings of a particular piece of software or architecture, then reason about why it may have certain 'bad' properties. This more often leads to action and mutual understanding, but requires actually putting in some mental effort. In your example, calling some code 'ugly' is another example of what I'm saying not to do, it is starting at a conclusion and reasoning backwards. For an example of what I'm advocating, say you started a project and defined certain architectural principles after a series of discussions with stakeholders. Let's say one of those principles is efficiency/speed of execution because the stakeholders use the software synchronously. So, that is how you define code quality in that project. You benchmark and eliminate hotspots until you reach acceptable performance. Independent of context, fast code may appear ugly to some people, but in this context it is not, perhaps it is even beautiful as it so embodies and elevates the architectural principle it was designed around. Developers now have a frame to surface issues and everyone can agree on what an issue is, because you defined what an issue looks like and why it is important, up front, as one of your architectural principles. This is basically a context-bound value system. There is no need to even use the words 'technical debt'. In a real project you have multiple competing architectural principles but these are prioritized so you know how to evaluate whether or not something is 'good' or 'bad'. As a project leader I believe it is your job to define these architectural principles, to enable developers to frame 'good and bad' as well as to prioritize their work. I used this approach when leading a project and it was very effective.
- Retric 5y ago
  If your code isn’t fast enough to meet spec, that’s just a defect. QA should create a ticket even if you don’t. There are however a meaningful class of issues that have zero direct impact outside the team, but are still issues for your team. The best example of that is how long it takes to setup your build environment, frankly your users have zero reason to care but it can still slow your teams progress over time. Really the cost and payoff of fixing it is simply time / a better work environment. Different teams will of course use technical debt to describe stuff outside of that context, but if it directly benefits users then it’s really something else.
chinchilla2020 5y ago
> ugly code Ugly code doesn't cause issues. Refactoring a reliable, functional, easily maintained codebase because it isn't elegant (or 'beautiful') is a waste of time.
- Retric 5y ago
  I think you’re describing something else. The defining characteristic of ugly code is it’s hard to reason about and thus not easy to maintain. It can still reliable, functional, and ugly.
  - dilyevsky 5y ago
    People (myself included) usually overestimate their ability to ship more readable code that has bug-for-bug parity with complex existing codebase.
    - Spivak 5y ago
      I think step zero for this kinda thing should be writing a test suite using the current code as the reference implementation. Then you spike it out with a first pass and if your clean version can’t get 90%+ without lots of edge case handling or abstraction breaking then you keep what you have.
      - dilyevsky 5y ago
        That’s exactly my point - chasing that 10% remainder will make the new thing similarly hacks-ridden as the original
    - Retric 5y ago
      I think you’re getting at a deeper issue. The need for bug-for-bug parity internally is itself a sign of technical debt. At this point we can’t for example fix historical calendars, so all highly accurate date and time related code is going to be complicated and full of edge cases. Such code is in effect an interest payment on society’s existing technical debt. So, the temptation to refactor such code is generally attacking the wrong side of a problem. The best approach may be to quarantine such code/systems and try and minimize the impact of such issues.
mmcnl 5y ago
What is the impact on the end user? Will anyone notice or care if you don't address the technical debt?
- Retric 5y ago
  In the platonic ideal of technical debut it should have zero direct impact on users. Indirect impacts are a slowdown in the release of new features, and or bug fixes etc.
  - mmcnl 5y ago
    Impact is impact. Slower roll-out of future releases is already way more specific than a vague arbitrary term "technical debt", right? I challenge you to come up with a situation where technical debt is a better way to describe activities than indirect impact as you are doing here.
    - Retric 5y ago
      How about someone saying “The X has _.” For one it’s more specific. Saying the existing code has indirect impact doesn’t even define if it’s a good or bad impact. If you want to say, the existing code has long description that just means technical debt then sure they mean the same thing but the term technical debt is more concise. You can still add all the low level details, but redundancy in communication still aids clarity.

NAHWheatCracker 5y ago

Talking about "real issues" doesn't always work. A few years ago, a director at my organization said at an all-hands meeting that he viewed "tech debt is a debt we never have to pay and have no interest on". In one swoop, he told the entire organization that technology concerns are not valid. People have been complaining for years using specific issues. We could point at times that important services went down. We could point at full time operations people who have to babysit applications. We could point at failed initiatives. The bi-annual company survey always has "we're fighting the same fires" in the top issues. I suppose the issue with talking about tech debt to non-technical people is that they don't care. It doesn't affect them. At least not directly, like it does for developers.

ma2rten 5y ago
It sounds like that company was just dysfunctional.
- NAHWheatCracker 5y ago
  There are good things and bad things. There is nuance. I haven't and can't provide the whole picture. I just provided one anecdote that I felt is relevant to the discussion here. In re-reading my comments, I think it's easier to interpret what I wrote in an only negative way. I think that dealing with technical debt is would be a topic that the company does poorly. On the flip side, they build new products quickly and use new tech often. I consider the organization to be similar to other big-company feature factories. There's a degree of dysfunction in that, but also has a purpose.
mmcnl 5y ago
If it doesn't affect the non-technical people, is it an issue then? I tend to be on the side of your director to be honest.
- NAHWheatCracker 5y ago
  It does affect them indirectly. More importantly, it affects the company. Engineer's lose motivation and put less effort in. The company has to spend more budget on operations. Emergencies come up. Projects fail to deliver on-time. These things are the tech debt and the interest being paid. He had a point in some cases. There are products that aren't used or aren't under active development. He was lumping all of the tech debt together. He was saying to everyone in the organization that he viewed all tech debt this way.

tyingq 5y ago

I agree. It's used for things that really do feel like debt. Perhaps a dependency on a library that no longer has support. But then it's also used for subjective things like "too monolithic" or "spaghetti code" where the value of fixing might not be clear. Or even that the issue is really an issue.

mmcnl 5y ago

It doesn't mean anything. Does a defined work package improve the product you are building in any way? Then plan the work. If not, then don't do it. I discourage using this term within my team, because it's not a transparent term.

nickm12 5y ago

Embrace the ambiguity. People argue what it means for something to be a sandwich as well, and "tech debt" is just a tad more ambiguous. But as a metaphor and concept, it seems to be quite sticky and we've been talking about it for thirty years now, so I think people find it useful despite the ambiguity. I recently explained tech debt to my 17 year old son, who is very interested in programming. It was difficult to come up with a crisp definition that captured what I mean by tech debt, but it was a good conversation.