17 ms·

Most Technical Debt Is Just Bullshit

37 points by louwrentius 6y ago

eutropia 6y ago
I think this post has inspired me to improve the specificity of why something I see in the code is bad. It's not always possible, because if I'm discovering the results of $SPECIFIC_REASON after the fact, often the context for why it's bad isn't obvious. When it's not obvious why it's bad, but is obvious that it should be changed: do I judgmentally call it a mess (that I didn't make)? Or should I declare it technical debt and endeavor to understand why the bad thing came to be?
- louwrentius 6y ago
  I would recommend to just call it for what it really is. Bad code. Why does it add anything to call it technical debt? You still have to dig deeper to really understand the problem anyway.
  - ineedasername 6y ago
    You can call it bad code, but someone wrote that bad code. A few people worked on the same team when the bad code got through the cracks. Someone supervised that team, etc. And some of those people, or people they know, are still working around you. Technical debt may not be the appropriate term, but there are good reasons to be a little more tactful than saying "I have to fix someone's bad code that broke" so that you can continue to have good working relationships with the people around you.
  - strken 6y ago
    Let's say I choose to hack together an interpretation layer for an API that another team controls instead of fixing their API's underlying issues. I'm deliberately choosing to write worse code for some business purpose (prototyping, legislative deadline, evaluating one API out of many, etc.). We assume that in the future other business purposes (stability, maintainability, other teams using the product, we decided on a direction) will necessitate more work to fix this hack. I need to explain to non-technical people that this will eventually need more work to be fixed. What metaphor should I use to explain taking on temporary business risk now to save time, then spending more time in total to fix it in the future?
  - rjkennedy98 6y ago
    > I would recommend to just call it for what it really is. Bad code If you work on a team, that just isn’t going to fly. I can’t imagine the toxicity of an environment where someone constantly was calling out other people’s code as being “bad”.
jelling 6y ago
Or sometimes it’s just when developers don’t like how something was implemented such as it’s OO and they believe it should be FP, or vice-versa. Or more annoying, when something doesn’t use their favorite library but it has zero impact on the user. The question I always ask is what happens if we do nothing? Debt at 0% interest is obviously not a problem.
- oriolid 6y ago
  Developers refusing to work on the code as it is doesn't sound like 0% interest to me.
  - jelling 6y ago
    That is not at all the scenario I described.
- aeternum 6y ago
  I see this very frequently, especially with newer developers. The code wasn't written using the paradigm they are familiar with or used at a previous company so they view the code as needing a refactor. Often the original paradigm was chosen for a reason and it becomes clear that the refactor was a step backwards. Any ideas on how to prevent this?
  - rendall 6y ago
    I don't know that it's possible to prevent it, but include the coder's perspective in a team conversations about the project, standards and such If it's innocuous and they have a bee in their bonnet, consider letting them refactor on their own branch, and subject it to normal code review Recount the Parable of Chesterton's Fence Ask them if they are just bikeshedding Let them make low cost mistakes to learn cheap lessons, saving expensive lessons later
  - habitue 6y ago
    > especially with newer developers My experience is junior and senior developers fall for this. > Often the original paradigm was chosen for a reason True, but the reason is often: - we didn't understand the problem domain as well when we wrote it - it was written this way because it needed to integrate with a system that existed at the time but no longer does - there was a guy who was really into X and he insisted on writing it this way. He no longer works here and no one wants to touch that code - It was written by an intern - It was written by a bad software developer (you're not morally bad for being a bad software developer, but they are real, and they write code) - It was written as a prototype and was supposed to be thrown out - It was written by me, and the fact that you want to rewrite it makes me feel bad > Any ideas on how to prevent this? Exploratory refactoring is actually a really good way to understand code deeply. Sometimes the refactor is bad and your throw it out, that's ok, you learned something. This applies to developers refactoring code, they learn the reasons for things as they rewrite it.
deeblering4 6y ago
Hmm, how does unfinished work differ from unfinished repayment of a debt (for example a mortgage)? In my view they both require continued ongoing maintenance to prevent negative consequences. And they both can be intimidating and/or not feasible to “pay off” at the current time. Just like financial debt, technical debt means accepting an ongoing burden and higher overall cost for a near term gain and avoidance of immediate lump sum payment of money/time.
- rjkennedy98 6y ago
  I was thinking the same thing. Debt is perfectly good metaphor for the collection of issues described. Just like one can get into financial debt via student loans or reckless credit card spending, tech debt can be accrued many ways. Additionally, talking about the origins of tech debt also misses one big thing - many of us primarily work on other people’s code. We inherit the debt, so it doesn’t matter how it gets there.
karmakaze 6y ago
If we look at the wikipedia page about technical debt, there is a long list of possible causes of technical debt. To site some examples: Insufficient up-front definition Lack of clear requirements before the start of development Lack of documentation Lack of a test suite Lack of collaboration / knowledge sharing Lack of knowledge/skills resulting in bad or suboptimal code Poor technical leadership Last minute specification changes Notice that these issues are called 'technical debt' because they can have a similar outcome as technical debt. They can create a bottleneck. But why the hell would we call these issues technical debt? These issues are self-explanatory. Calling them technical debt not only seems inappropriate, it just obfuscates the cause of these problems and it doesn't provide any new insight. None of those were called 'tech debt'--they were cited as common causes. How each case is handled may lead to tech debt.
- srtjstjsj 6y ago
  Please don't use indentation for blockquote. HN markdown (and most other markdown) doesn't support that.
jl2718 6y ago
We play a fun game at work. It’s called “code parkour”. You can always add more code. You can always move code into a new class or module. But nobody may ever delete anything.
- rotifer 6y ago
  Move everything you'd like to delete into DeadCodeModule and make it all private, or would that be considered unsporting?
pjbster 6y ago
The biggest contributor to technical debt is the mindset of "if it ain't broke, don't fix it". This gives everyone permission to just wait for issues to appear on the tracker before even looking at the code after it's gone live. When issues do start to come in, the next blocker arises: the dreaded Cost Benefit Analysis. If a data fix can be applied in, say, 30 minutes and the business is seeing one of these every week, it's easy to live with the cost if the alternative is to spend 30 man-hours on pushing a fix through "the process". (I'm talking about shops which haven't been able to move to CI yet. Shops which rely on a dedicated System Test team and a dedicated Release Management team. Shops which require downtime to ship fixes of any sort and which require a release slot booked at least 24 hours in advance.) Furthermore, that 30 minutes of hassle making the data fix isn't felt by the manager whereas shepherding a fix through the release process most certainly will be. A codebase that has been shaped over the years by this combination of mindset and process is probably too ossified to refactor by the time it's recognised as a problem. Cue the "chains of habit..." quote.
known 6y ago
Listed companies have to show profits to shareholders every 100 days aka technical debt
ineedasername 6y ago
I think of technical debt as either 1) deferred maintenance or 2) systems, even when properly maintained, slowly aging into "legacy". I wasn't really aware there was a much broader use of the term than that. Although I guess you you can overload the "deferred maintenance" category quite a bit if you get creative.
- toast0 6y ago
  "Legacy" really just means stuff that we used to do that we still need to do. Usually, it's the system that works, but employees don't like. Often it's also the one that actually books revenue. If the non-legacy system provided value, you could convince users to switch to it instead of a competitor, and your old system could be retired instead of legacy.
  - ineedasername 6y ago
    I use legacy a little differently to mean systems that have actually aged to obsolescence, as in they are no longer maintained by the vendor, no more security upgrades or other ToS updates. I suppose it could also apply to any system used prior to the current one. However I see the term applied to any system as young as 5-7 years old. I suppose in cutting edge areas of computing this may be the case, but not at all for things like ERP software that underpins the business. Major versions of systems like that often have a minimum maintenance horizon of 10 years on release, a clear roadmap, and a relatively smooth update path when new major releases come along. Where I work, we recently upgraded from Version 8.x of such a system, which the vendor had maintained for 15 years, to version 9.x. We'd upgraded into 8.x only a few years earlier from a truly legacy system had run for most of 30 years. It still worked fine, and was faster than what we have now. We didn't update because the system wasn't doing what it was supposed to do: we updated because we wanted to do some new things, and because the vendor after decades and multiple extensions, stopped providing annual compliance updates for state & federal regulations, which also would have been extremely costly to produce ourselves (not to mention being a major legal risk if we got something wrong, and the vendor had previously indemnified us if they made an error of that sort). Otherwise we might very happily have turned to various "best-of-bread" stand-alone options for the new functionality we needed and then hired a couple of extra database jockeys to manage the complex ETL & data warehouse needed to make it work nicely.
jopsen 6y ago
A mess is a mess, but calling it "technical debt" allows us to talk about it without blaming anyone. If you accuse something of being a mess that should be rewritten/refactored, some people may feel hurt which is counter productive.
- mewpmewp2 6y ago
  Also talking about it in negative terms can create bias towards perfection. The bigger the company becomes the more important good code becomes, but in the beginning you might have to cut a lot of corners in order to get to market as soon as possible in order to start making money. In same way you would take a loan to get off the ground faster. If you want to write perfect code, yes coverage during that time it will simply take many times more time and 6 months to market might change into few years. In start ups that became big people often complain about existing code being a mess, but if it wasn't created as mess the company wouldn't ever had become that big.
alephu5 6y ago
Where I work we use the term technical debt to differentiate between work that has been requested for business reasons (by the CTO, VP of engineering or product managers), and improvements that developers think can help us work faster with fewer bugs (tech. debt). Given that there is a continuous change of priorities, knowledge and staff with different skill levels, it's just a fact of life that we accumulate some crappy design and lack of documentation. I think it's useful to have a label for this because it needs a different process for judging it's merit than customer or performance-oriented changes.
tsjq 6y ago
quick fixes, shortcuts, ignoring known future risks, half-assery, "jugaad" , "it's okay for now" , meet-deadline-at-all-costs, are some of the prime contributors to technical debt.
nickm12 6y ago
Well, I agree with the author that trying to formalize "tech debt" is not that valuable, but disagree with the conclusion that tech debt is bullshit, either as a metaphor or a meaningful concept we can use to make decisions. I take a broad view of tech debt and include all the things: corners cut to ship; (2) missing tooling (tests, linters, CI/CD etc.); deferred maintenance (platform updates, etc.); and just plain "messes". What all of these have in common is that they are work that needs to be done in the future if the software is to remain usable and maintainable. They also interact—for example, it can be difficult to update your platform if you don't have a good test suite to catch regressions. Anecdotally, I've been working in a codebase for the past couple of years that had a ton of tech debt. It was a tarball of Python 2 code with no tests or other tooling. My team has been delivering new features but also addressing the debt. Now the codebase is Python 3, with build-time typechecking and linting. Lots of copy-paste code has been consolidated into libraries with good test coverage. This refactoring cost us time, but it is now paying off. Our development velocity is so much better and we're delivering features faster, with fewer bugs. It feels like our time has more "principal" and less "interest" to it. I know part of it is that the refactoring work necessarily made us more familiar with the codebase, but I also know that there is just less debt in the system.
goto11 6y ago
Technical debt is a great metaphor because it is easy to understand for management. Calling code "a mess" does not really communicate why it should be improved. Who cares if it is a mess if it works? What developers actually mean with "a mess" is that the code gets increasingly harder to maintain which incurs cost down the road. Technical debt is a good metaphor to explain this.
- mewpmewp2 6y ago
  Exactly. This is not a term for developers. It is to explain tradeoffs or current state for anyone looking at the big picture. I think the article is misunderstanding that we makes the whole article moot.
  - erikpukinskis 6y ago
    I’ve been working on a project at work to try to measure the interest paid on technical debt. And I think developers are the only people who can really measure that. Their time is the cost. The only way to understand how much of it is paying principal, how much is paying interest, and how much of it is just “buying stuff we actually need” comes down to having that conversation with the engineers. One of the big things I’ve learned speaks to your point though: it’s not a natural way of thinking for most engineers. There are a few who are “natural complainers” who can tell the difference between “work that needs to be done” and “work I have to do because someone took a shortcut in the past”. But actually many of the “natural complainers”, while they have strong “this is insane” detectors, they often complain about anything that’s not perfect. But that’s not exactly what we want. Many things are not perfect but they’re pretty easy to work around. That’s not an interest payment it’s just an annoyance. And on the other side of the spectrum there are a lot of coders who have a “whatever it takes” mindset, and they can’t really perceive interest paid at all. To them, every necessary thing is reasonable. If it has to be done it has to be done. They don’t really think about how it could be done more easily in a different world... because we’re not in that world! Why think about a hypothetical! So, I have some more thinking to do about how to teach folks to think critically about their time and past decisions. And the other big learning I got is the recording of interest payments is only useful if it’s somewhat regular. So I think it has to be an official, required part of the production process. If people have to remember to report on interest paid, they just won’t. The project is on pause right now, but I’d like to give it another shot with those things in mind. I think I’m going to wait until a time when it feels like it fits in with the needs of the managers though. Otherwise that second piece of “part of the process” is gonna be hard. But if I can at least put an “interest paid” number on some tasks, my hope is that will provide a good way to identify which projects will “pay off” if they are “paid off”. Basically I want a vaguely rigorous way to put refractors and infrastructure work up against new features so they can be compared 1:1 during planning. Also feel free to email me if anyone is interested in something like this at their company.
fold_left 6y ago
I recently heard someone say this, which I thought was interesting: > Technical Debt is the result of a weak definition of done
scott_meyer 6y ago
"Technical debt" is the difference between the code that you have and the code that you would write if starting over. Does your final code reflect what you learned while writing it? "Technical surplus" is your ability to learn and implement that learning as code. The "bullshit" part is complaining about debt while not being able to run a surplus.
Udik 6y ago
To summarize many comments: A debt is something that gave you value in the past. If nobody ever got value out of it (in comparison to an equally feasible debt-less solution), then it was just a mistake, not a debt. A debt is something you pay an ongoing interest on. If your proposed solution to the technical debt is not provably reducing the ongoing costs, then you're not actually addressing a technical debt.
- fuzzfactor 6y ago
  Even without interest, a debt is something that needs to be paid back or you might go bankrupt.

37 points by louwrentius 6y ago

I think this post has inspired me to improve the specificity of why something I see in the code is bad. It's not always possible, because if I'm discovering the results of $SPECIFIC_REASON after the fact, often the context for why it's bad isn't obvious. When it's not obvious why it's bad, but is obvious that it should be changed: do I judgmentally call it a mess (that I didn't make)? Or should I declare it technical debt and endeavor to understand why the bad thing came to be?

louwrentius 6y ago
I would recommend to just call it for what it really is. Bad code. Why does it add anything to call it technical debt? You still have to dig deeper to really understand the problem anyway.
- ineedasername 6y ago
  You can call it bad code, but someone wrote that bad code. A few people worked on the same team when the bad code got through the cracks. Someone supervised that team, etc. And some of those people, or people they know, are still working around you. Technical debt may not be the appropriate term, but there are good reasons to be a little more tactful than saying "I have to fix someone's bad code that broke" so that you can continue to have good working relationships with the people around you.
- strken 6y ago
  Let's say I choose to hack together an interpretation layer for an API that another team controls instead of fixing their API's underlying issues. I'm deliberately choosing to write worse code for some business purpose (prototyping, legislative deadline, evaluating one API out of many, etc.). We assume that in the future other business purposes (stability, maintainability, other teams using the product, we decided on a direction) will necessitate more work to fix this hack. I need to explain to non-technical people that this will eventually need more work to be fixed. What metaphor should I use to explain taking on temporary business risk now to save time, then spending more time in total to fix it in the future?
- rjkennedy98 6y ago
  > I would recommend to just call it for what it really is. Bad code If you work on a team, that just isn’t going to fly. I can’t imagine the toxicity of an environment where someone constantly was calling out other people’s code as being “bad”.

jelling 6y ago

Or sometimes it’s just when developers don’t like how something was implemented such as it’s OO and they believe it should be FP, or vice-versa. Or more annoying, when something doesn’t use their favorite library but it has zero impact on the user. The question I always ask is what happens if we do nothing? Debt at 0% interest is obviously not a problem.

oriolid 6y ago
Developers refusing to work on the code as it is doesn't sound like 0% interest to me.
- jelling 6y ago
  That is not at all the scenario I described.
aeternum 6y ago
I see this very frequently, especially with newer developers. The code wasn't written using the paradigm they are familiar with or used at a previous company so they view the code as needing a refactor. Often the original paradigm was chosen for a reason and it becomes clear that the refactor was a step backwards. Any ideas on how to prevent this?
- rendall 6y ago
  I don't know that it's possible to prevent it, but include the coder's perspective in a team conversations about the project, standards and such If it's innocuous and they have a bee in their bonnet, consider letting them refactor on their own branch, and subject it to normal code review Recount the Parable of Chesterton's Fence Ask them if they are just bikeshedding Let them make low cost mistakes to learn cheap lessons, saving expensive lessons later
- habitue 6y ago
  > especially with newer developers My experience is junior and senior developers fall for this. > Often the original paradigm was chosen for a reason True, but the reason is often: - we didn't understand the problem domain as well when we wrote it - it was written this way because it needed to integrate with a system that existed at the time but no longer does - there was a guy who was really into X and he insisted on writing it this way. He no longer works here and no one wants to touch that code - It was written by an intern - It was written by a bad software developer (you're not morally bad for being a bad software developer, but they are real, and they write code) - It was written as a prototype and was supposed to be thrown out - It was written by me, and the fact that you want to rewrite it makes me feel bad > Any ideas on how to prevent this? Exploratory refactoring is actually a really good way to understand code deeply. Sometimes the refactor is bad and your throw it out, that's ok, you learned something. This applies to developers refactoring code, they learn the reasons for things as they rewrite it.

deeblering4 6y ago

Hmm, how does unfinished work differ from unfinished repayment of a debt (for example a mortgage)? In my view they both require continued ongoing maintenance to prevent negative consequences. And they both can be intimidating and/or not feasible to “pay off” at the current time. Just like financial debt, technical debt means accepting an ongoing burden and higher overall cost for a near term gain and avoidance of immediate lump sum payment of money/time.

rjkennedy98 6y ago
I was thinking the same thing. Debt is perfectly good metaphor for the collection of issues described. Just like one can get into financial debt via student loans or reckless credit card spending, tech debt can be accrued many ways. Additionally, talking about the origins of tech debt also misses one big thing - many of us primarily work on other people’s code. We inherit the debt, so it doesn’t matter how it gets there.

karmakaze 6y ago

If we look at the wikipedia page about technical debt, there is a long list of possible causes of technical debt. To site some examples: Insufficient up-front definition Lack of clear requirements before the start of development Lack of documentation Lack of a test suite Lack of collaboration / knowledge sharing Lack of knowledge/skills resulting in bad or suboptimal code Poor technical leadership Last minute specification changes Notice that these issues are called 'technical debt' because they can have a similar outcome as technical debt. They can create a bottleneck. But why the hell would we call these issues technical debt? These issues are self-explanatory. Calling them technical debt not only seems inappropriate, it just obfuscates the cause of these problems and it doesn't provide any new insight. None of those were called 'tech debt'--they were cited as common causes. How each case is handled may lead to tech debt.

srtjstjsj 6y ago
Please don't use indentation for blockquote. HN markdown (and most other markdown) doesn't support that.

jl2718 6y ago

We play a fun game at work. It’s called “code parkour”. You can always add more code. You can always move code into a new class or module. But nobody may ever delete anything.

rotifer 6y ago
Move everything you'd like to delete into DeadCodeModule and make it all private, or would that be considered unsporting?

pjbster 6y ago

The biggest contributor to technical debt is the mindset of "if it ain't broke, don't fix it". This gives everyone permission to just wait for issues to appear on the tracker before even looking at the code after it's gone live. When issues do start to come in, the next blocker arises: the dreaded Cost Benefit Analysis. If a data fix can be applied in, say, 30 minutes and the business is seeing one of these every week, it's easy to live with the cost if the alternative is to spend 30 man-hours on pushing a fix through "the process". (I'm talking about shops which haven't been able to move to CI yet. Shops which rely on a dedicated System Test team and a dedicated Release Management team. Shops which require downtime to ship fixes of any sort and which require a release slot booked at least 24 hours in advance.) Furthermore, that 30 minutes of hassle making the data fix isn't felt by the manager whereas shepherding a fix through the release process most certainly will be. A codebase that has been shaped over the years by this combination of mindset and process is probably too ossified to refactor by the time it's recognised as a problem. Cue the "chains of habit..." quote.

known 6y ago

Listed companies have to show profits to shareholders every 100 days aka technical debt

ineedasername 6y ago

I think of technical debt as either 1) deferred maintenance or 2) systems, even when properly maintained, slowly aging into "legacy". I wasn't really aware there was a much broader use of the term than that. Although I guess you you can overload the "deferred maintenance" category quite a bit if you get creative.

toast0 6y ago
"Legacy" really just means stuff that we used to do that we still need to do. Usually, it's the system that works, but employees don't like. Often it's also the one that actually books revenue. If the non-legacy system provided value, you could convince users to switch to it instead of a competitor, and your old system could be retired instead of legacy.
- ineedasername 6y ago
  I use legacy a little differently to mean systems that have actually aged to obsolescence, as in they are no longer maintained by the vendor, no more security upgrades or other ToS updates. I suppose it could also apply to any system used prior to the current one. However I see the term applied to any system as young as 5-7 years old. I suppose in cutting edge areas of computing this may be the case, but not at all for things like ERP software that underpins the business. Major versions of systems like that often have a minimum maintenance horizon of 10 years on release, a clear roadmap, and a relatively smooth update path when new major releases come along. Where I work, we recently upgraded from Version 8.x of such a system, which the vendor had maintained for 15 years, to version 9.x. We'd upgraded into 8.x only a few years earlier from a truly legacy system had run for most of 30 years. It still worked fine, and was faster than what we have now. We didn't update because the system wasn't doing what it was supposed to do: we updated because we wanted to do some new things, and because the vendor after decades and multiple extensions, stopped providing annual compliance updates for state & federal regulations, which also would have been extremely costly to produce ourselves (not to mention being a major legal risk if we got something wrong, and the vendor had previously indemnified us if they made an error of that sort). Otherwise we might very happily have turned to various "best-of-bread" stand-alone options for the new functionality we needed and then hired a couple of extra database jockeys to manage the complex ETL & data warehouse needed to make it work nicely.

jopsen 6y ago

A mess is a mess, but calling it "technical debt" allows us to talk about it without blaming anyone. If you accuse something of being a mess that should be rewritten/refactored, some people may feel hurt which is counter productive.

mewpmewp2 6y ago
Also talking about it in negative terms can create bias towards perfection. The bigger the company becomes the more important good code becomes, but in the beginning you might have to cut a lot of corners in order to get to market as soon as possible in order to start making money. In same way you would take a loan to get off the ground faster. If you want to write perfect code, yes coverage during that time it will simply take many times more time and 6 months to market might change into few years. In start ups that became big people often complain about existing code being a mess, but if it wasn't created as mess the company wouldn't ever had become that big.

alephu5 6y ago

Where I work we use the term technical debt to differentiate between work that has been requested for business reasons (by the CTO, VP of engineering or product managers), and improvements that developers think can help us work faster with fewer bugs (tech. debt). Given that there is a continuous change of priorities, knowledge and staff with different skill levels, it's just a fact of life that we accumulate some crappy design and lack of documentation. I think it's useful to have a label for this because it needs a different process for judging it's merit than customer or performance-oriented changes.

tsjq 6y ago

quick fixes, shortcuts, ignoring known future risks, half-assery, "jugaad" , "it's okay for now" , meet-deadline-at-all-costs, are some of the prime contributors to technical debt.

nickm12 6y ago

Well, I agree with the author that trying to formalize "tech debt" is not that valuable, but disagree with the conclusion that tech debt is bullshit, either as a metaphor or a meaningful concept we can use to make decisions. I take a broad view of tech debt and include all the things: corners cut to ship; (2) missing tooling (tests, linters, CI/CD etc.); deferred maintenance (platform updates, etc.); and just plain "messes". What all of these have in common is that they are work that needs to be done in the future if the software is to remain usable and maintainable. They also interact—for example, it can be difficult to update your platform if you don't have a good test suite to catch regressions. Anecdotally, I've been working in a codebase for the past couple of years that had a ton of tech debt. It was a tarball of Python 2 code with no tests or other tooling. My team has been delivering new features but also addressing the debt. Now the codebase is Python 3, with build-time typechecking and linting. Lots of copy-paste code has been consolidated into libraries with good test coverage. This refactoring cost us time, but it is now paying off. Our development velocity is so much better and we're delivering features faster, with fewer bugs. It feels like our time has more "principal" and less "interest" to it. I know part of it is that the refactoring work necessarily made us more familiar with the codebase, but I also know that there is just less debt in the system.

goto11 6y ago

Technical debt is a great metaphor because it is easy to understand for management. Calling code "a mess" does not really communicate why it should be improved. Who cares if it is a mess if it works? What developers actually mean with "a mess" is that the code gets increasingly harder to maintain which incurs cost down the road. Technical debt is a good metaphor to explain this.

mewpmewp2 6y ago
Exactly. This is not a term for developers. It is to explain tradeoffs or current state for anyone looking at the big picture. I think the article is misunderstanding that we makes the whole article moot.
- erikpukinskis 6y ago
  I’ve been working on a project at work to try to measure the interest paid on technical debt. And I think developers are the only people who can really measure that. Their time is the cost. The only way to understand how much of it is paying principal, how much is paying interest, and how much of it is just “buying stuff we actually need” comes down to having that conversation with the engineers. One of the big things I’ve learned speaks to your point though: it’s not a natural way of thinking for most engineers. There are a few who are “natural complainers” who can tell the difference between “work that needs to be done” and “work I have to do because someone took a shortcut in the past”. But actually many of the “natural complainers”, while they have strong “this is insane” detectors, they often complain about anything that’s not perfect. But that’s not exactly what we want. Many things are not perfect but they’re pretty easy to work around. That’s not an interest payment it’s just an annoyance. And on the other side of the spectrum there are a lot of coders who have a “whatever it takes” mindset, and they can’t really perceive interest paid at all. To them, every necessary thing is reasonable. If it has to be done it has to be done. They don’t really think about how it could be done more easily in a different world... because we’re not in that world! Why think about a hypothetical! So, I have some more thinking to do about how to teach folks to think critically about their time and past decisions. And the other big learning I got is the recording of interest payments is only useful if it’s somewhat regular. So I think it has to be an official, required part of the production process. If people have to remember to report on interest paid, they just won’t. The project is on pause right now, but I’d like to give it another shot with those things in mind. I think I’m going to wait until a time when it feels like it fits in with the needs of the managers though. Otherwise that second piece of “part of the process” is gonna be hard. But if I can at least put an “interest paid” number on some tasks, my hope is that will provide a good way to identify which projects will “pay off” if they are “paid off”. Basically I want a vaguely rigorous way to put refractors and infrastructure work up against new features so they can be compared 1:1 during planning. Also feel free to email me if anyone is interested in something like this at their company.

fold_left 6y ago

I recently heard someone say this, which I thought was interesting: > Technical Debt is the result of a weak definition of done

scott_meyer 6y ago

"Technical debt" is the difference between the code that you have and the code that you would write if starting over. Does your final code reflect what you learned while writing it? "Technical surplus" is your ability to learn and implement that learning as code. The "bullshit" part is complaining about debt while not being able to run a surplus.

Udik 6y ago

To summarize many comments: A debt is something that gave you value in the past. If nobody ever got value out of it (in comparison to an equally feasible debt-less solution), then it was just a mistake, not a debt. A debt is something you pay an ongoing interest on. If your proposed solution to the technical debt is not provably reducing the ongoing costs, then you're not actually addressing a technical debt.

fuzzfactor 6y ago
Even without interest, a debt is something that needs to be paid back or you might go bankrupt.