10 ms·

Unpopular opinion, probably here, but definitely among people I've shared this with before: The phrase technical debt is a red flag itself and probably should n

Unpopular opinion, probably here, but definitely among people I've shared this with before: The phrase technical debt is a red flag itself and probably should never be used. Most people seem to get that the issue of technical debt is really a business issue about tradeoffs. So, if the person who is concerned about technical debt is senior enough they will have some ability to see the business tradeoff and thus can completely avoid the phrase. They'd say instead something like "I was thinking that if we changed X we would get value Y." A person who uses the phrase Technical Debt is signaling that they aren't capable of saying something that direct. That's one issue. And then the other issue is that a huge amount of technical debt is just code that a more senior engineer would refactor as they went. It's a junior engineer who says, "this is a huge mess and I need a full stop of my contributions to the business so that I can focus on untangling it." But the problem with junior engineers doing refactoring/rewriting is that they end up creating a different mess of code and bugs. Am I right 100% of the time about this? No. But I'd love to raise for engineers here that although the phrase technical debt caries a lot of emotional weight, it also brings a lot of baggage from all the times management has heard the phrase from someone that didn't understand the bigger picture. With a little bit of work you could understand the business implications and then end up completely avoiding the use of the phrase.

dvt 6y ago
> And then the other is that a huge amount of technical debt is just code that a more senior engineer would refactor as they went. I'm quite senior, and I don't think this is true. Refactoring "as you go" is a no-go for a few reasons: (1) Roadmap (read: business) goals need to be reached and unless technical debt is a part of roadmap discussions -- it's usually not, because business people don't "get" code -- then it will naturally be of lower priority. (2) On a technical level, technical debt changes/re-arch should not live in feature branches. On a deeper technical level, technical debt pull requests and reviews will also usually incur a higher level of cognitive load (and thus will take longer to merge). Conflating technical debt and new features is a Bad Idea™. (3) This final point is a bit "20-20 hindsight," but with proper roadmapping and architecting (and unless you're building an MVP or proof of concept at your two-person startup), technical debt should basically not exist. Technical leaders should always push for high-quality code (even if product timelines are stretched) and technical debt is, generally speaking, a byproduct of bad technical leadership.
- darkerside 6y ago
  Disagree on point 3. Technical debt is not bad code. It's expedient decisions made to achieve short term business value at a long term cost. On point 2, you're right they should be separate, but I think the solution is, refactor to make your solution easy, then build the solution. Point 1, if you have a significant rearchitecture to mention on your roadmap, do so. But don't make the mistake of thinking business leadership cares. You'll get farther with strong technical leaders who can push for appropriate timelines, not haggle over technical tradeoffs with executives. Parent post is terrific and makes a lot of great points.
  - epicureanideal 6y ago
    I think technical debt can be either. I agree with you that it isn't by definition bad code, but it can also be bad code. Let's also not assume an ideal case where every bit of tech debt was the best possible code that could be written under the time constraints of the time... with absolutely no influence due to lack of skill, ownership, motivation, etc. of the author.
    - weego 6y ago
      Tech debt is a luxury that only a measure of success affords. If you work in entprise and find bad code that's just plain old vanilla bad engineering and we should carve that out of the definition. If you work in early stage or barely mature then the luxury of defining and scoping tech debt is something that should be treated as a necessary step to maturity. After all, whatever you think of the code or design decisions you've found, it has clearly justified itself just on basis that the company is successful enough for you to be there finding it.
      - epicureanideal 6y ago
        I think this is more of a survivorship bias thing. If a bunch of companies write bad code and a few of them survive, so you work at those companies and see their bad code, it isn't necessarily true that permitting bad code enabled them to succeed. It may be that writing better code would've made them even more likely to succeed, but the advocates of better code were not able to make that case to stressed out management. I've almost never seen a situation where intentionally bad code has helped even in the short term. Maybe bad code was the best that a particular engineer could do, and nobody else was available to do it, so that made it acceptable. But any engineer writing code less well than they are able to has never led to anything good in my experience. Even in 45 minute interviews, if I take shortcuts, I usually end up creating more problems for myself than if I had just written code the right way in the first place.
RegnisGnaw 6y ago
Of course it shouldn't be used. The company I worked with has relabeled 'Technical Debt' as 'Technical Wealth Investment'. Not sure how it helps, but somehow still nothing gets done.
renewiltord 6y ago
Strongly agree. It's just trade-offs. Tying debt relief to demonstrable value is good. Refactoring without that is prone to vanity stuff, Chesterton's fence, second system effect, etc.
AntiImperialist 6y ago
Agree. It's just tradeoffs. Some projects don't warrant over engineering because the requirements are often not clear in the beginning. There's a cost in terms of resources and opportunity which often doesn't make sense to incur at an earlier stage of product development. As the first few versions play out in the market, the requirements are better understood, the product starts fitting the market better. Obviously, a lot of the earlier choices don't seem optimal for what the product becomes at a later time. Yes, theoretically, "it could have been done better", but nobody could have known for sure. It should simply be refactored so that the design of the software better fits what it is doing at a given time... and this should be an expected way to develop products. I think "technical debt" is often the wrong term for what is going on. I'm sure there is a better analogy in terms of business and finance to what is happening... but I'm not well-versed in finance to say what it is.
- tonystubblebine 6y ago
  > wrong term for what's going on. Exactly. It's such a loaded term and it can almost always be replaced by saying something specific.
  - cutemonster 6y ago
    I didn't know it can be a loaded term (for some people). What are some things to say instead? "Past mistakes" maybe? In some cases
- dhsysusbsjsi 6y ago
  Agree - I came here to say the same thing. Most engineers have an eye for quality and maintainability which is great, however what they sometimes fail to see is that in a commercial reality, rapidly iterating on features to be first mover advantage is "worth" the piles of dirty dishes incurred, even if it's a huge headache later on maintaining it. Often it's an existential threat - you either move fast (and often do the 95% solution to ship) or you are gone. I find quite often engineers without the big picture/reality of the business can often forget that everything is an engineering tradeoff and maybe copy+paste and a bit of spaghetti is your friend today because your firm just expanded. All of the previous analogies about libraries and dishes need an added layer: if they shut down for a week at the start to re-organise and clean, perhaps they would have gone bankrupt and the stupid solution may have actually been the best one all along.
prionassembly 6y ago
Our experiences with freelancers who signal velocity by making 40% of the stuff happen quickly and then say "we have to stop and refactor, it's too messy". This being a website on which they've been working for a couple of months.
leto_ii 6y ago
> So, if the person who is concerned about technical debt is senior enough they will have some ability to see the business tradeoff and thus can completely avoid the phrase. They'd say instead something like "I was thinking that if we changed X we would get value Y." In my (somewhat limited) experience the kind of value that you get from reducing technical debt is not easy to explain to the business side, because it doesn't immediately translate into new features. > And then the other issue is that a huge amount of technical debt is just code that a more senior engineer would refactor as they went. A limited amount of spaghetti can be untangled during the normal development process, but I don't think significant changes in design can be done while working on features. Once you get to that point, inevitably you will have to set time aside specifically for dealing with tech debt. Not to mention that the kind of organizations that accumulate tech debt rapidly tend to also complain if you spend more than the minimal amount of time necessary on a feature. "It took you, a mid-level dev, 3 days to finish a feature that a starter could complete in a day by copy-pasting existing code with some SO stuff? You must not be too good at your job."
- Jtsummers 6y ago
  > In my (somewhat limited) experience the kind of value that you get from reducing technical debt is not easy to explain to the business side, because it doesn't immediately translate into new features. This is because, regardless of whether people agree on its definition, most of the things that fall under "technical debt" incur indirect or delayed costs for the business. The managers have, at some point, a choice: We have $X. We can either spend some percentage on churning out products that directly and immediately make us money. Or we can divide it between that, and maintenance activities. Choosing to neglect (or underfund) the maintenance activities doesn't cost the business anything for some period of time (the delay). And performing them does not (within the period of that delay) bring in any revenue. It is only a cost to them, it has no visible upside within their time horizon. By the time the costs start catching up, it's death by a thousand cuts. Usually they'll go from 100/0 dev/maintenance to 99/1, then 98/2, and so on. Then one day it flips from 80/20 to 20/80 and they realized they fucked up. But by then they've been promoted, so who cares? You have to convince them, and perhaps they'll only learn by being burned (but I doubt it), that they should extend their time horizon by a month or a year so they can see the consequence of this decision. I've never succeeded in this. At my previous job we were experiencing a massive number of retirements. Literally centuries of experience leaving every month (aggregated across all teams). No hiring process, without comprehensive training, could possibly keep up with this loss. But the retirements were always (for each team) just far enough over the horizon that they didn't realize the issues until after the retirement and the new hire floundered (due to lack of training/mentorship).
gregmac 6y ago
> although the phrase technical debt caries a lot of emotional weight, it also brings a lot of baggage from all the times management has heard the phrase from someone that didn't understand the bigger picture. I think this is an excellent point, but we still need a shorthand way to talk about it. > They'd say instead something like "I was thinking that if we changed X we would get value Y." The problem I have with this is it's very hard to make a compelling argument, and without one, nothing gets done. A lot of the time technical debt is tantamount to a slow death by a thousand cuts, and "value Y" is more like "save some unknown but non-zero amount of time in the future". One example is when you have (tens of) thousands of lines of code that don't have unit tests, have high coupling, and no or outdated documentation. Maybe there's some known bugs, but they're of low importance (in other words: fixing them is low value to the business). That code works today, and if not modified it'll continue to work. If it does eventually get modified, then there are no guarantees: maybe the modifications won't break anything, or maybe they'll cause dozens of new bugs. If we refactor today and add lots of tests, it'll probably mean that future modification causes fewer bugs (saving time/money), but we actually can't guarantee anything -- aside from the refactor will cost a bunch of time, now. > a huge amount of technical debt is just code that a more senior engineer would refactor as they went In a case like I described above you can sometimes refactor as you go but it's been my experience this is often a deep rabbit hole. Sometimes your refactor requires touching a dozen layers and related bits and before you know it it can easily be several orders of magnitude more work and more risk vs the "quick fix". Another thing I often run into that we describe as "technical debt" is about foundational designs that are (currently) wrong. This includes things like database schema and core structure of the application. I say "currently" because some where not clearly wrong at the time they were made, but it had become clear since then and yet more stuff was still built on top. As an example, I'm working on an application that was built to run on a single instance but we'd like to be able to scale horizontally. One of the problems is the application uses what is effectively an in-process cache for a lot of the database objects. The objects are not pure DTO-style objects and so the cache can't just be moved to external (Redis or something). The schema is not that well designed, so entirely removing the cache would almost certainly kill performance, and might mean refactoring half the code anyway. A layer up, several parts of the app (including UI forms and some background processing) are built assuming they have a consistent view of things, and ignoring these issues causes all kinds of strange consistency problems as data is silently overwritten/changed. That type of problem is not at all fixable by "refactoring as we go". In some sense I'd love to do a totally clean rewrite, but that just isn't going to happen largely because the business has no appetite for that. In the past I've done the massive rewrite thing before, and going a couple years without delivering anything from it is crazy stressful and no one is happy. Instead, we're working on rewriting major (but approachable) chunks of this one at a time, while retaining compatibility with other parts of the system and still trying to find things that provide customer/business value as part of it (either fixing long-standing bugs or introducing new features). It's hard, and overall is more work than just rewriting from scratch, but means we can deliver value as we go. Maybe this is what you mean by "refactor as we go" (or maybe that's just how I should describe what we're doing to higher-up), but to me we're basically starting from zero and at best, pulling small chunks of the old code in, so it definitely doesn't feel like "refactor". (I know this post is explicitly about not calling this "technical debt" but I can't help but think this approach is analogous to a payment plan. :) )
mcot2 6y ago
Thank you for this comment. It matches quite closely with my thinking on the issue. A generic term like “tech debt” is lazy and does not capture anything about the business value or decision making process that led to the code or would lead you to want to replace it. For example in many organizations you make a completely justified business decision to put less time or more junior engineers on a project that isn’t that important. This isn’t tech debt, it’s a conscious decision made by completely rational people. On the flip side, if that project that was of lesser importance becomes important again you can make another completely rational decision to go in and clean it up to make it faster/more reliable/simpler or whatever the goal may be.
- pseudalopex 6y ago
  Debt you can afford is still called debt.
louwrentius 6y ago
I 100% agree, the concept of Technical Debt doesn't exist in any other profession. I think that's a clue. In most cases, the concept doesn't really clarify anything, but people don't seem to know how to translate 'our' problems into something that is actually meaningful for the other people in the room. The term 'technical debt' just obfuscates what is really going on. It doesn't provide any real insight. You may like the blog post I linked in another post here.
- Jtsummers 6y ago
  It most definitely does exist. They just don't call it that. Every organization that's responsible for a system that produces their revenue and requires upkeep runs into this, they just either don't have a specific name or it's not a name we (programmers) see. See: http://web.mit.edu/nelsonr/www/Repenning%3DSterman_CMR_su01_.pdf http://web.mit.edu/nelsonr/www/Repenning%3DSterman_CMR_su01_... [pdf] for an example of an analysis of a technical debt analog in other industries.
  - louwrentius 6y ago
    Thank you, this is maybe my point: don't use this 'technical debt' term that everybody and their horse abuses, but use those concepts that are also well-understood in other industries. Does that sound acceptable?
    - breakfastduck 6y ago
      Technical Debt is just another name for those concepts that are well understood in industries, but renamed to be directly applicable to the type of work.
      - Jtsummers 6y ago
        And it should be noted that "technical debt" appears to have been coined before "capability trap". And many other industries lack a proper term to describe the same concept, even if they possess it.
allenu 6y ago
I agree with your assessment. Using the language "tech debt" makes it appear that there is a correct way to design something and that if you're not doing it that way, you will need to pay a debt on it, now or later. The reality is it's all trade-offs and sometimes those debts never need to be paid at all. "Bad code" that is reliable within the constraints it is exercised and that is isolated may appear to have to tech debt, as in "if we changed the design, we could support XYZ feature" but if XYZ feature never materializes, it's a waste of time to touch it. Maybe we can come up with more appropriate language for this? Something akin to "inflexible" code. Calling something "debt" assigns too much subjective value to it while making it seem objective.
- cutemonster 6y ago
  It seems you think "debt" is a bad word. To me it's a neutral word
  - allenu 6y ago
    I think for the general public "debt" has negative connotations. It's something that they feel must be repaid later. It definitely can be a financial tool and can be neutral, but I don't think most people think of it that way.
spfzero 6y ago
But isn't the term "Technical Debt" meant to help business-people understand an issue that, while real, and though inherently grasped by people who write software, not necessarily by others in positions to make resource allocation decisions? By calling it "debt" it is put into financial terms everyone understands. If it is a red flag, it is in the sense that people are making decisions about software, who don't understand how it is built and maintained. That is the case in a lot of environments.
- mmcnl 6y ago
  There is an underlying assumption business people are unable to understand the real issue. That seems weird to me. Also technical debt seems like an escape for engineers to do things they want so but don't feel like explaining why.
mmcnl 6y ago
Fully agree!
Alex3917 6y ago
> The phrase technical debt is a red flag itself and probably should never be used. I think the counter argument is that not everything needs to get turned into a negotiation around justifying business value. Each developer should just by default get 25% of the year to improve the code they're responsible for. If a developer wants to spend 6 or 9 months one year doing some big refactor then that's one thing, but it's not a good work environment if there needs to be weeks of meetings every time someone wants to fix deprecations so that they can upgrade some library or whatever.
- tonystubblebine 6y ago
  Oh for sure. I believe this 100%. A lot of the root cause of technical debt is inability to prioritize. Every stake holder in the company wants to hear that their project is being worked on and so everyone is working in parallel and thus there are tons of meetings for coordination and status. And if everyone would just slow down they would actually move a lot faster and could afford to bake in slack time for craftsmanship.
Forge36 6y ago
There are three parts to a problem. Why what how. "Technical debt" is the what. "Change X we would get value Y" is why. (How do it if left as an exercise to the reader)
hinkley 6y ago
There are a lot of expert beginners that make a mess so big that it takes ages to unravel their ball of mud. Most of the time by the time people are talking about it, it's because it's way too big for anyone to ignore. I had a notion that this can never get so big that you can't unravel it, but I think it's a matter of how much power the problem people have. I've seen one project that will be broken forever because, while they've gotten a couple of the biggest architectural astronauts away from it, one of the most prolific will never leave, and does not accept that just because you can do something doesn't mean you should do it.
kstrauser 6y ago
I disagree, but I see technical debt differently than it's usually used. When you buy a house, or start a company, you commonly borrow resources to have the thing you want today instead of years from now. I think technical debt is exactly the same: you're borrowing future work so that you can launch your product now instead of far in the future after you have it absolutely perfect. It's a little wild to imaging buying a house without incurring some debt. This is normal and OK. You don't go crazy with it, though, like getting a loan for 20% over the mortgage with a 12% interest rate. Same with technical debt: cut a few corners if it lets you go to market more quickly and start earning income before your competitors can launch, but not at the cost of utter spaghetti code written in MUMPS or something. Your class hierarchy isn't perfect? Fine - your customers aren't paying you for that anyway. So go ahead and borrow. Just don't go so far in debt that paying it off becomes burdensome.

dvt 6y ago

> And then the other is that a huge amount of technical debt is just code that a more senior engineer would refactor as they went. I'm quite senior, and I don't think this is true. Refactoring "as you go" is a no-go for a few reasons: (1) Roadmap (read: business) goals need to be reached and unless technical debt is a part of roadmap discussions -- it's usually not, because business people don't "get" code -- then it will naturally be of lower priority. (2) On a technical level, technical debt changes/re-arch should not live in feature branches. On a deeper technical level, technical debt pull requests and reviews will also usually incur a higher level of cognitive load (and thus will take longer to merge). Conflating technical debt and new features is a Bad Idea™. (3) This final point is a bit "20-20 hindsight," but with proper roadmapping and architecting (and unless you're building an MVP or proof of concept at your two-person startup), technical debt should basically not exist. Technical leaders should always push for high-quality code (even if product timelines are stretched) and technical debt is, generally speaking, a byproduct of bad technical leadership.

darkerside 6y ago
Disagree on point 3. Technical debt is not bad code. It's expedient decisions made to achieve short term business value at a long term cost. On point 2, you're right they should be separate, but I think the solution is, refactor to make your solution easy, then build the solution. Point 1, if you have a significant rearchitecture to mention on your roadmap, do so. But don't make the mistake of thinking business leadership cares. You'll get farther with strong technical leaders who can push for appropriate timelines, not haggle over technical tradeoffs with executives. Parent post is terrific and makes a lot of great points.
- epicureanideal 6y ago
  I think technical debt can be either. I agree with you that it isn't by definition bad code, but it can also be bad code. Let's also not assume an ideal case where every bit of tech debt was the best possible code that could be written under the time constraints of the time... with absolutely no influence due to lack of skill, ownership, motivation, etc. of the author.
  - weego 6y ago
    Tech debt is a luxury that only a measure of success affords. If you work in entprise and find bad code that's just plain old vanilla bad engineering and we should carve that out of the definition. If you work in early stage or barely mature then the luxury of defining and scoping tech debt is something that should be treated as a necessary step to maturity. After all, whatever you think of the code or design decisions you've found, it has clearly justified itself just on basis that the company is successful enough for you to be there finding it.
    - epicureanideal 6y ago
      I think this is more of a survivorship bias thing. If a bunch of companies write bad code and a few of them survive, so you work at those companies and see their bad code, it isn't necessarily true that permitting bad code enabled them to succeed. It may be that writing better code would've made them even more likely to succeed, but the advocates of better code were not able to make that case to stressed out management. I've almost never seen a situation where intentionally bad code has helped even in the short term. Maybe bad code was the best that a particular engineer could do, and nobody else was available to do it, so that made it acceptable. But any engineer writing code less well than they are able to has never led to anything good in my experience. Even in 45 minute interviews, if I take shortcuts, I usually end up creating more problems for myself than if I had just written code the right way in the first place.

RegnisGnaw 6y ago

Of course it shouldn't be used. The company I worked with has relabeled 'Technical Debt' as 'Technical Wealth Investment'. Not sure how it helps, but somehow still nothing gets done.

renewiltord 6y ago

Strongly agree. It's just trade-offs. Tying debt relief to demonstrable value is good. Refactoring without that is prone to vanity stuff, Chesterton's fence, second system effect, etc.

AntiImperialist 6y ago

Agree. It's just tradeoffs. Some projects don't warrant over engineering because the requirements are often not clear in the beginning. There's a cost in terms of resources and opportunity which often doesn't make sense to incur at an earlier stage of product development. As the first few versions play out in the market, the requirements are better understood, the product starts fitting the market better. Obviously, a lot of the earlier choices don't seem optimal for what the product becomes at a later time. Yes, theoretically, "it could have been done better", but nobody could have known for sure. It should simply be refactored so that the design of the software better fits what it is doing at a given time... and this should be an expected way to develop products. I think "technical debt" is often the wrong term for what is going on. I'm sure there is a better analogy in terms of business and finance to what is happening... but I'm not well-versed in finance to say what it is.

tonystubblebine 6y ago
> wrong term for what's going on. Exactly. It's such a loaded term and it can almost always be replaced by saying something specific.
- cutemonster 6y ago
  I didn't know it can be a loaded term (for some people). What are some things to say instead? "Past mistakes" maybe? In some cases
dhsysusbsjsi 6y ago
Agree - I came here to say the same thing. Most engineers have an eye for quality and maintainability which is great, however what they sometimes fail to see is that in a commercial reality, rapidly iterating on features to be first mover advantage is "worth" the piles of dirty dishes incurred, even if it's a huge headache later on maintaining it. Often it's an existential threat - you either move fast (and often do the 95% solution to ship) or you are gone. I find quite often engineers without the big picture/reality of the business can often forget that everything is an engineering tradeoff and maybe copy+paste and a bit of spaghetti is your friend today because your firm just expanded. All of the previous analogies about libraries and dishes need an added layer: if they shut down for a week at the start to re-organise and clean, perhaps they would have gone bankrupt and the stupid solution may have actually been the best one all along.

prionassembly 6y ago

Our experiences with freelancers who signal velocity by making 40% of the stuff happen quickly and then say "we have to stop and refactor, it's too messy". This being a website on which they've been working for a couple of months.

leto_ii 6y ago

> So, if the person who is concerned about technical debt is senior enough they will have some ability to see the business tradeoff and thus can completely avoid the phrase. They'd say instead something like "I was thinking that if we changed X we would get value Y." In my (somewhat limited) experience the kind of value that you get from reducing technical debt is not easy to explain to the business side, because it doesn't immediately translate into new features. > And then the other issue is that a huge amount of technical debt is just code that a more senior engineer would refactor as they went. A limited amount of spaghetti can be untangled during the normal development process, but I don't think significant changes in design can be done while working on features. Once you get to that point, inevitably you will have to set time aside specifically for dealing with tech debt. Not to mention that the kind of organizations that accumulate tech debt rapidly tend to also complain if you spend more than the minimal amount of time necessary on a feature. "It took you, a mid-level dev, 3 days to finish a feature that a starter could complete in a day by copy-pasting existing code with some SO stuff? You must not be too good at your job."

Jtsummers 6y ago
> In my (somewhat limited) experience the kind of value that you get from reducing technical debt is not easy to explain to the business side, because it doesn't immediately translate into new features. This is because, regardless of whether people agree on its definition, most of the things that fall under "technical debt" incur indirect or delayed costs for the business. The managers have, at some point, a choice: We have $X. We can either spend some percentage on churning out products that directly and immediately make us money. Or we can divide it between that, and maintenance activities. Choosing to neglect (or underfund) the maintenance activities doesn't cost the business anything for some period of time (the delay). And performing them does not (within the period of that delay) bring in any revenue. It is only a cost to them, it has no visible upside within their time horizon. By the time the costs start catching up, it's death by a thousand cuts. Usually they'll go from 100/0 dev/maintenance to 99/1, then 98/2, and so on. Then one day it flips from 80/20 to 20/80 and they realized they fucked up. But by then they've been promoted, so who cares? You have to convince them, and perhaps they'll only learn by being burned (but I doubt it), that they should extend their time horizon by a month or a year so they can see the consequence of this decision. I've never succeeded in this. At my previous job we were experiencing a massive number of retirements. Literally centuries of experience leaving every month (aggregated across all teams). No hiring process, without comprehensive training, could possibly keep up with this loss. But the retirements were always (for each team) just far enough over the horizon that they didn't realize the issues until after the retirement and the new hire floundered (due to lack of training/mentorship).

gregmac 6y ago

> although the phrase technical debt caries a lot of emotional weight, it also brings a lot of baggage from all the times management has heard the phrase from someone that didn't understand the bigger picture. I think this is an excellent point, but we still need a shorthand way to talk about it. > They'd say instead something like "I was thinking that if we changed X we would get value Y." The problem I have with this is it's very hard to make a compelling argument, and without one, nothing gets done. A lot of the time technical debt is tantamount to a slow death by a thousand cuts, and "value Y" is more like "save some unknown but non-zero amount of time in the future". One example is when you have (tens of) thousands of lines of code that don't have unit tests, have high coupling, and no or outdated documentation. Maybe there's some known bugs, but they're of low importance (in other words: fixing them is low value to the business). That code works today, and if not modified it'll continue to work. If it does eventually get modified, then there are no guarantees: maybe the modifications won't break anything, or maybe they'll cause dozens of new bugs. If we refactor today and add lots of tests, it'll probably mean that future modification causes fewer bugs (saving time/money), but we actually can't guarantee anything -- aside from the refactor will cost a bunch of time, now. > a huge amount of technical debt is just code that a more senior engineer would refactor as they went In a case like I described above you can sometimes refactor as you go but it's been my experience this is often a deep rabbit hole. Sometimes your refactor requires touching a dozen layers and related bits and before you know it it can easily be several orders of magnitude more work and more risk vs the "quick fix". Another thing I often run into that we describe as "technical debt" is about foundational designs that are (currently) wrong. This includes things like database schema and core structure of the application. I say "currently" because some where not clearly wrong at the time they were made, but it had become clear since then and yet more stuff was still built on top. As an example, I'm working on an application that was built to run on a single instance but we'd like to be able to scale horizontally. One of the problems is the application uses what is effectively an in-process cache for a lot of the database objects. The objects are not pure DTO-style objects and so the cache can't just be moved to external (Redis or something). The schema is not that well designed, so entirely removing the cache would almost certainly kill performance, and might mean refactoring half the code anyway. A layer up, several parts of the app (including UI forms and some background processing) are built assuming they have a consistent view of things, and ignoring these issues causes all kinds of strange consistency problems as data is silently overwritten/changed. That type of problem is not at all fixable by "refactoring as we go". In some sense I'd love to do a totally clean rewrite, but that just isn't going to happen largely because the business has no appetite for that. In the past I've done the massive rewrite thing before, and going a couple years without delivering anything from it is crazy stressful and no one is happy. Instead, we're working on rewriting major (but approachable) chunks of this one at a time, while retaining compatibility with other parts of the system and still trying to find things that provide customer/business value as part of it (either fixing long-standing bugs or introducing new features). It's hard, and overall is more work than just rewriting from scratch, but means we can deliver value as we go. Maybe this is what you mean by "refactor as we go" (or maybe that's just how I should describe what we're doing to higher-up), but to me we're basically starting from zero and at best, pulling small chunks of the old code in, so it definitely doesn't feel like "refactor". (I know this post is explicitly about not calling this "technical debt" but I can't help but think this approach is analogous to a payment plan. :) )

mcot2 6y ago

Thank you for this comment. It matches quite closely with my thinking on the issue. A generic term like “tech debt” is lazy and does not capture anything about the business value or decision making process that led to the code or would lead you to want to replace it. For example in many organizations you make a completely justified business decision to put less time or more junior engineers on a project that isn’t that important. This isn’t tech debt, it’s a conscious decision made by completely rational people. On the flip side, if that project that was of lesser importance becomes important again you can make another completely rational decision to go in and clean it up to make it faster/more reliable/simpler or whatever the goal may be.

pseudalopex 6y ago
Debt you can afford is still called debt.

louwrentius 6y ago

I 100% agree, the concept of Technical Debt doesn't exist in any other profession. I think that's a clue. In most cases, the concept doesn't really clarify anything, but people don't seem to know how to translate 'our' problems into something that is actually meaningful for the other people in the room. The term 'technical debt' just obfuscates what is really going on. It doesn't provide any real insight. You may like the blog post I linked in another post here.

Jtsummers 6y ago
It most definitely does exist. They just don't call it that. Every organization that's responsible for a system that produces their revenue and requires upkeep runs into this, they just either don't have a specific name or it's not a name we (programmers) see. See: http://web.mit.edu/nelsonr/www/Repenning%3DSterman_CMR_su01_.pdf http://web.mit.edu/nelsonr/www/Repenning%3DSterman_CMR_su01_... [pdf] for an example of an analysis of a technical debt analog in other industries.
- louwrentius 6y ago
  Thank you, this is maybe my point: don't use this 'technical debt' term that everybody and their horse abuses, but use those concepts that are also well-understood in other industries. Does that sound acceptable?
  - breakfastduck 6y ago
    Technical Debt is just another name for those concepts that are well understood in industries, but renamed to be directly applicable to the type of work.
    - Jtsummers 6y ago
      And it should be noted that "technical debt" appears to have been coined before "capability trap". And many other industries lack a proper term to describe the same concept, even if they possess it.

allenu 6y ago

I agree with your assessment. Using the language "tech debt" makes it appear that there is a correct way to design something and that if you're not doing it that way, you will need to pay a debt on it, now or later. The reality is it's all trade-offs and sometimes those debts never need to be paid at all. "Bad code" that is reliable within the constraints it is exercised and that is isolated may appear to have to tech debt, as in "if we changed the design, we could support XYZ feature" but if XYZ feature never materializes, it's a waste of time to touch it. Maybe we can come up with more appropriate language for this? Something akin to "inflexible" code. Calling something "debt" assigns too much subjective value to it while making it seem objective.

cutemonster 6y ago
It seems you think "debt" is a bad word. To me it's a neutral word
- allenu 6y ago
  I think for the general public "debt" has negative connotations. It's something that they feel must be repaid later. It definitely can be a financial tool and can be neutral, but I don't think most people think of it that way.

spfzero 6y ago

But isn't the term "Technical Debt" meant to help business-people understand an issue that, while real, and though inherently grasped by people who write software, not necessarily by others in positions to make resource allocation decisions? By calling it "debt" it is put into financial terms everyone understands. If it is a red flag, it is in the sense that people are making decisions about software, who don't understand how it is built and maintained. That is the case in a lot of environments.

mmcnl 6y ago
There is an underlying assumption business people are unable to understand the real issue. That seems weird to me. Also technical debt seems like an escape for engineers to do things they want so but don't feel like explaining why.

mmcnl 6y ago

Fully agree!

Alex3917 6y ago

> The phrase technical debt is a red flag itself and probably should never be used. I think the counter argument is that not everything needs to get turned into a negotiation around justifying business value. Each developer should just by default get 25% of the year to improve the code they're responsible for. If a developer wants to spend 6 or 9 months one year doing some big refactor then that's one thing, but it's not a good work environment if there needs to be weeks of meetings every time someone wants to fix deprecations so that they can upgrade some library or whatever.

tonystubblebine 6y ago
Oh for sure. I believe this 100%. A lot of the root cause of technical debt is inability to prioritize. Every stake holder in the company wants to hear that their project is being worked on and so everyone is working in parallel and thus there are tons of meetings for coordination and status. And if everyone would just slow down they would actually move a lot faster and could afford to bake in slack time for craftsmanship.

Forge36 6y ago

There are three parts to a problem. Why what how. "Technical debt" is the what. "Change X we would get value Y" is why. (How do it if left as an exercise to the reader)

hinkley 6y ago

There are a lot of expert beginners that make a mess so big that it takes ages to unravel their ball of mud. Most of the time by the time people are talking about it, it's because it's way too big for anyone to ignore. I had a notion that this can never get so big that you can't unravel it, but I think it's a matter of how much power the problem people have. I've seen one project that will be broken forever because, while they've gotten a couple of the biggest architectural astronauts away from it, one of the most prolific will never leave, and does not accept that just because you can do something doesn't mean you should do it.

kstrauser 6y ago

I disagree, but I see technical debt differently than it's usually used. When you buy a house, or start a company, you commonly borrow resources to have the thing you want today instead of years from now. I think technical debt is exactly the same: you're borrowing future work so that you can launch your product now instead of far in the future after you have it absolutely perfect. It's a little wild to imaging buying a house without incurring some debt. This is normal and OK. You don't go crazy with it, though, like getting a loan for 20% over the mortgage with a 12% interest rate. Same with technical debt: cut a few corners if it lets you go to market more quickly and start earning income before your competitors can launch, but not at the cost of utter spaghetti code written in MUMPS or something. Your class hierarchy isn't perfect? Fine - your customers aren't paying you for that anyway. So go ahead and borrow. Just don't go so far in debt that paying it off becomes burdensome.