8 ms·

I think the author is basically diluting the term "technical debt" to the point it becomes meaningless. Much of what they are talking about is the inherent dif

by ska 3y ago

I think the author is basically diluting the term "technical debt" to the point it becomes meaningless. Much of what they are talking about is the inherent difficulty of managing complexity, mixed with the difficulty of understanding requirements/defining features well. I think "technical debt" as a term is overused and sometimes misapplied, but the core idea resonates with many developers, at least the way it is most often used - which isn't exactly the original proposal as another commentpoints out. The key part of it is the analogy with an interest rate. I can decide do put 5k on the credit card for a last minute holiday, but for as long as I don't pay that off, I'm paying 20-something percent, every month, forever. Similarly for example a rush to add features to hit a demo deadline can introduce brittleness and abstraction failures into your codebase that you pay for every time you make changes, add features, do nearly anything. The analogy is that some of your development is going to be wasted "servicing the debt" going forward until you fix that (pay off the debt). That doesn't mean its the wrong move, for the same reasons that taking on debt can be the right move for a person or business.

sorokod 3y ago
Yes, a bit silly this. Code is means to an end, it makes sence to think of code as liability (maintenance cost, inevitable bugs, etc .. ) but this must be contrasted with the value it provides within some reasonable timeframe.
- deleted 3y ago
  [deleted]
seadan83 3y ago
I don't think the analogy breaks down per-say. Adding features is akin to adding a percentage interest rate. Some add more than others, but the cost of adding a feature is sometimes (often) dependent upon the existing features in the system. Coding & story-writing is a good analogy. If you are inserting a new scene into a large anthology, you need to make sure the new scene fits with everything else. OTOH, writing a brand new story does not have this constraint / cost. Which is all to say, software is an asset, code is a cost. The functionality of software is the valuable thing, all the code to do that is overhead. Thus, every line of code has a cost, and an ongoing cost that is forever then payed (which is exactly the interest; simply taking the time to scan/read over a line, to scan between 5 files vs 20, those are all ongoing costs)
- ska 3y ago
  I disagree. Scaling things up has a cost, but not all costs are debt financed. I think the distinction is worth drawing.
  - bgirard 3y ago
    That's a good response. I can buy a house cash, I can buy a house with a 5% mortgage, or I could buy a house with a 20+% loan. Rushing out features with known bugs, poor architecture, no test and no documentation is akin to buying a house with a 20+% loan. You'll get your house sooner but you'll spend most of your resources servicing that debt until you can pay it down.
  - seadan83 3y ago
    It's a useful distinction, but not necessarily at odds with what I'm trying to say. I'm more saying that all code has interest on it. "bad code" is high interest, "good code" has interest that at times is close to zero. Another response gives the construction analogy (I try to avoid construction analogies for software building, because it's a bad analogy.. but I would digress - story writing & editing I think is a much stronger analogy for software development). Let's say there exists two townhomes side-by-side (attached building). Let's say you need to replace one. The cost to replace one is a function of its attachments to adjacent buildings and overall build quality. If that other building were not there, all costs associated with compability would be zero. We can draw this analogy much further though, let's say to inspect the electrical lines - you need to remove half of the dry-wall of the existing building that you do not want to even touch. Had the electrical lines been put in correctly, that re-do and re-painting of the interior, the temporary eviction of tenants would all be unnecessary. This is the example of the overhead that comes with code. Anything that is 'attached' to something else is going to be more expensive to do anything with compared to it not being 'attached' to something else. The cost of considering and maintaining that attachment is not related to the value provided by that attachment, but instead to the quality of the attachment. The 'debt financed' metaphor comes in when instead of doing something right, it's done badly which means anything that is attached to the 'badly done thing', needs to incur a high overhead cost to even just understand the badly done thing (every time, and whether we are even trying to modify it or not - this is high interest code). In comparison, if the system is decoupled and the APIs clean, that other thing might need only a moment of consideration instead (low interest code) At the end of the day, it is to say - if you are replacing the 11th floor of a building, you have to consider every floor whether you want to or not. That is more expensive than if you did not have to consider those other floors. Considering the impact to 10 other floors is always more expensive than if those floors did not exist at all. The cost of maintaining those floors though is not a fixed cost, not all floors have the same maintenance cost. The maintenance cost of equivalent floors is not even the same, it's a function of the quality of those floors. Even high quality floors can be low-quality if we are trying to do something the designers did not expect. It's very context dependent, but all of which is to say that the value from features is significantly independent of the cost of the thing that delivers those features. The thing that delivers those feature might be very high cost, or it might be low - but it will have a non-zero maintenance cost. Simply reading a list of 10 items is more expensive than reading a list of 5 items. If anything, those extra "5" modules have at least that overhead cost, it's not zero. The debt financing analogy comes in to describe how high that interest rate is. Saying "code" is a cost is essentially just saying that all code has a non-zero maintenance cost (maintenance being the activity of reading, understanding, debugging, modifying, or deleting code).
deleted 3y ago
[deleted]
crazygringo 3y ago
Completely agreed. The idea that "all code is technical debt" because all requirements could hypothetically change someday, makes as much sense as saying "all currencies have no value" because 1,000 years from now we might not be using any of them. Technical debt is not defined in terms of possible future requirements, it is defined in terms of current requirements. Code that elegantly and concisely expresses current requirements is debt-free. Code that is a mix of elegantly expressing old requirements, with new requirements expressed in a hacky fast way, has debt. But trying to judge code in reference to all possible future requirements is utterly nonsensical. You can't measure that. It's literally meaningless. So no, all code is not technical debt. Technical debt is technical debt, and clean code is clean code. Trying to redefine words to mean their opposite helps no one. That way lies madness.
- posix86 3y ago
  But dept can only recognized if you're trying to implement something new, and notice that you have to pay interest. Poorly written code makes it very hard to implement new features & debug existing one, while well written code makes it easy. So the current dept can only be estimated with respect of features you are implementing in the future.
  - majikandy 3y ago
    Seems fair to assume that “current requirements” means current roadmap of requirements. Taken to extreme, if there are no future requirements at all, there is no technical debt.
chuckadams 3y ago
My brother coined a term that I really love: "feature karma". He's an actual Buddhist, so he used the term "karma" not to mean a simple score with only positive connotations, but as something you're chained to and must work off should you at some point want to move past it.
- CSMastermind 3y ago
  I often try to explain the concept of Technical Wealth as the other side of the spectrum from Technical Debt. Technical Wealth pays dividends; Tech Debt charges interest on which the payments will eventually become unwieldy. That doesn't mean you shouldn't take on Technical Debt, like many startups do with real money you can and should go into debt in order to get your business off the ground. But just like irresponsible financial management can kill your company, so can irresponsible technical management.
Phiwise_ 3y ago
Absolutely agreed. Articles in this vein rather get my goat, especially because the analogy to real debt is more clear: If someone wrote a consumer finance article like "All purchases of things other than cans of beans and Certificates of Deposit are like Mortgages, because what if your industry collapses tomorrow?" most people have the good sense to complain that the usually decent advice of saving a bit for a rainy day was being way exaggerated. And yet pieces that run something like "All programming of things other than washing machine microcontrollers are like technical debt, because what if your customer's needs suddenly change entirely?" get much more play. Sure, disasters can happen, and it pays to reserve some resources to be ready for them, but it also pays to use resources when times are good to expand. It seems to me Cunningham's point was to encourage a move towards balance; headlines that don't overshoot the mark.
j45 3y ago
Well said. Too often code is a proxy for complexity being added unnecessarily, consciously or unconsciously. Premature optimization or over-engineering or burning your innovation points on shiny object syndrome can create technical debt in a different way than just taking shortcuts.
NoPicklez 3y ago
I agree and I can't stand it when people dilute terms to the point they become meaningless. I see it in other areas as well. It isn't a profound thought to take a term like "technical debt" and just say well that's just everything. Technical debt is absolutely that, adding something that incurs a level of interest, until you take the time to pay it off. In life, we often always have a level of interest to be paid. It's a good analogy
- rjzzleep 3y ago
  Almost ten years ago I had the unfortunate opportunity to work with a master manipulator who was unfortunately more senior in the hierarchy. Most of his code was actually technical debt. The code that wasn’t was external code he integrated. All of the code he wrote would eventually break down and until it did world force you to work around it, so it wouldn’t fail from interfacing with it. In one of the standup’s i used the term technical debt to argue for fixing one of these issues that broke later but which he discouraged everyone to fix. After that he integrated the term into his daily use to the point that it became meaningless. The people that believed this snake oil salesman thought that he had already carefully weighed his own decisions in advance. Needless to say the issue was not fixed before he left the company and cost millions and plenty of customer headaches.
ljm 3y ago
I think it could make more sense if it's rephrased to 'all code is a liability'. Then the equation is simpler. More code = more to maintain = more liability. It says nothing about the quality of the code, just the quantity. Tech debt is a trade-off between near term and long term ambitions - it is literally impossible to build a successful project without accruing this kind of debt, simply because you cannot perfectly anticipate the future. In that sense, it's not so much debt as it is a maintenance overhead.
- code_biologist 3y ago
  I agree with the general sentiment but would generalize to "all corporate surface area is a liability" and that liability can be minimized in many ways. An illustrative example where more code is a lesser liability: I work on a product with an activity feed feature built in 2018-19. There was a political battle on whether to build it internally or use a third party "feed as a service" product. The build it internally folks won. The "FaaS" under consideration went under during the pandemic, so we dodged that bullet. We also have customized it in ways not possible with an off the shelf product, with no big rewrite necessary. On the flipside, we've never had time to implement things that are trivial with commercial FaaS like iOS and Android push notifications. Trade-offs are hard!
- opportune 3y ago
  Agreed, or similarly: all software has a carrying (maintenance, but I think that has connotations of not including full ongoing TCO) cost. Code is a liability in the sense that it has a non-zero carrying cost. The ideal software implementing a given functionality has as low of a carrying cost as possible. More code, in quantity and complexity, typically means more carrying costs. One of the appeals of SAAS is that this carrying cost is easy to quantify and predict. Going further, for high-quality OSS projects like the Linux Kernel, the carrying cost may be 0 or close to 0 for most users. But lower quality OSS or buggy SAAS has a carrying cost in the form of bugs (possibly affecting downstream users), patches, need for support + back and forth. In this analogy tech debt is a tradeoff for some short term benefit (like simplicity, time to market) at the expense of higher carrying costs down the line. But some carrying costs simply can’t be reduced - you can’t mooch off something like the Linux kernel, get your own carrying costs all the way to 0, or find a SAAS provider/vendor willing to give you the software for free. So in this model not all code is technical debt.
mmcnl 3y ago
What I don't like about "technical debt" is that it's usually interpreted as "technical" debt: it's only a problem for the developers, the techies. You immediately lose the business stakeholders once you start talking about technical debt. But the problem of technical debt if a problem for everyone, not just the devs, because it is reflected in quality and time-to-market. I feel having that conversation about time-to-market and quality with business stakeholders is incredibly important and is often skipped. This in turn alienates business stakeholders from the developers, which is counter-productive. So yes, the core idea of technical debt resonates with developers, but not with business stakeholders. So if you really think the business is going to be okay with "we're gonna slow down our time-to-market and say no to all your requests for a while because we need to pay back our technical debt" (which is something I see happening over and over again), you're just keeping them out of the loop and taking over their responsibilities without actually having their accountability. Developers shouldn't decide whether time and money should be invested in time-to-market and quality or feature delivery, but that's effectively what's happening when business is not involved in the tech debt discussion. This only leads to friction and suboptimal results. That's why I think we really need to be careful when using the words "technical debt" and not just label everything we don't really understand or think can be improved as "technical debt". Challenge yourself: what really is the problem with this piece of code, other than that we don't like it?
- convolvatron 3y ago
  unless its a perfect shining jewel - every piece of existing code constrains future development, until progress asymptotically approaches zero and development cost asymptotically approaches infinity
  - hnfong 3y ago
    > every piece of existing code constrains future development If that were literally true, then every new development would rationally necessitate a total rewrite of the codebase. You might have meant that parts of the existing codebase would need to be changed to adapt to the new development, but as long as you've made a rational decision to keep using parts of the existing codebase, it must have been a net positive otherwise you'd just throw it all away.
matheusmoreira 3y ago
I agree. Technical debt is a very useful concept and it's not helpful to dilute its meaning. Only a couple days ago I decided to change some data structure. It was needlessly hard because I had neglected to create an accessor function and was instead accessing it directly everywhere. Had to change every bit of code that accessed the structure's fields. That's technical debt: something the programmer should have done but for whatever reason didn't. I paid back the debt by doing it: I created the function. Now if I want to change the data structure I only have to update the function. If I hadn't paid it back, it would start accruing interest: it would be even harder in the future as more and more stuff accessed the fields.
- avereveard 3y ago
  No sorry that is just bad encapsulation and goes under poor programming.Technical debt occurs when you write a good program to your current understanding of the solution knowing that the full understanding of the solution will come later, and that you need to do something now to get to that learning point later, and so you have to repay your partial understanding at the beginning with refactoring later. Here, heed Ward words directly, poor programming is not debt, and debt doesn't cover "whatever reason programmer may have" but has a specific well defined scope: https://m.youtube.com/watch?v=pqeJFYwnkjE&t=198 https://m.youtube.com/watch?v=pqeJFYwnkjE&t=198
  - jimmaswell 3y ago
    That's certainly not how most people understand the term.
    - avereveard 3y ago
      I mean that is the guy who invented it should we just go "ah well the uneducated masses really wish for a term that excuses bad programming so let's twist this nice metaphor into something we can sell to management to that effect", or instead just get the quote and correct people whenever we can until there's no more shadow under which to hide bad code.
  - 3y ago
wredue 3y ago
I especially likes the discussion of “adding assumptions” where it became readily apparent that there was zero experience guiding anything in their product, and when they said “assumption”, what they actually meant was “completely and utterly devoid of any semblance of planning what-so-ever”
Aeolun 3y ago
> The analogy is that some of your development is going to be wasted "servicing the debt" going forward until you fix that (pay off the debt). This is the same for bog standard development though. Any code you add, regardless of whether it is termed technical debt or not, will make your future development slower. Like you say, that doesn’t mean it’s the wrong move, you want to build a product after all, but I think I can see where the author comes from.
- seanhunter 3y ago
  That's not true at all. There are lots of circumstances where adding (good) code adds velocity. Imagine I'm trying to do a bunch of graphics stuff. The code I write to integrate a 3rd party graphics library will make my future development faster. I am effectively creating a lever I will later use to increase my productivity. Say I need to do a bunch of linear algebra. Code I write to calculate dot products, determinants etc (or better yet to use a library to do those things) will greatly accellerate progress later and enable me to think in terms of the linear transformations I'm trying to accomplish rather than the underlying primitive operations.

by ska 3y ago

sorokod 3y ago

Yes, a bit silly this. Code is means to an end, it makes sence to think of code as liability (maintenance cost, inevitable bugs, etc .. ) but this must be contrasted with the value it provides within some reasonable timeframe.

deleted 3y ago
[deleted]

seadan83 3y ago

I don't think the analogy breaks down per-say. Adding features is akin to adding a percentage interest rate. Some add more than others, but the cost of adding a feature is sometimes (often) dependent upon the existing features in the system. Coding & story-writing is a good analogy. If you are inserting a new scene into a large anthology, you need to make sure the new scene fits with everything else. OTOH, writing a brand new story does not have this constraint / cost. Which is all to say, software is an asset, code is a cost. The functionality of software is the valuable thing, all the code to do that is overhead. Thus, every line of code has a cost, and an ongoing cost that is forever then payed (which is exactly the interest; simply taking the time to scan/read over a line, to scan between 5 files vs 20, those are all ongoing costs)

ska 3y ago
I disagree. Scaling things up has a cost, but not all costs are debt financed. I think the distinction is worth drawing.
- bgirard 3y ago
  That's a good response. I can buy a house cash, I can buy a house with a 5% mortgage, or I could buy a house with a 20+% loan. Rushing out features with known bugs, poor architecture, no test and no documentation is akin to buying a house with a 20+% loan. You'll get your house sooner but you'll spend most of your resources servicing that debt until you can pay it down.
- seadan83 3y ago
  It's a useful distinction, but not necessarily at odds with what I'm trying to say. I'm more saying that all code has interest on it. "bad code" is high interest, "good code" has interest that at times is close to zero. Another response gives the construction analogy (I try to avoid construction analogies for software building, because it's a bad analogy.. but I would digress - story writing & editing I think is a much stronger analogy for software development). Let's say there exists two townhomes side-by-side (attached building). Let's say you need to replace one. The cost to replace one is a function of its attachments to adjacent buildings and overall build quality. If that other building were not there, all costs associated with compability would be zero. We can draw this analogy much further though, let's say to inspect the electrical lines - you need to remove half of the dry-wall of the existing building that you do not want to even touch. Had the electrical lines been put in correctly, that re-do and re-painting of the interior, the temporary eviction of tenants would all be unnecessary. This is the example of the overhead that comes with code. Anything that is 'attached' to something else is going to be more expensive to do anything with compared to it not being 'attached' to something else. The cost of considering and maintaining that attachment is not related to the value provided by that attachment, but instead to the quality of the attachment. The 'debt financed' metaphor comes in when instead of doing something right, it's done badly which means anything that is attached to the 'badly done thing', needs to incur a high overhead cost to even just understand the badly done thing (every time, and whether we are even trying to modify it or not - this is high interest code). In comparison, if the system is decoupled and the APIs clean, that other thing might need only a moment of consideration instead (low interest code) At the end of the day, it is to say - if you are replacing the 11th floor of a building, you have to consider every floor whether you want to or not. That is more expensive than if you did not have to consider those other floors. Considering the impact to 10 other floors is always more expensive than if those floors did not exist at all. The cost of maintaining those floors though is not a fixed cost, not all floors have the same maintenance cost. The maintenance cost of equivalent floors is not even the same, it's a function of the quality of those floors. Even high quality floors can be low-quality if we are trying to do something the designers did not expect. It's very context dependent, but all of which is to say that the value from features is significantly independent of the cost of the thing that delivers those features. The thing that delivers those feature might be very high cost, or it might be low - but it will have a non-zero maintenance cost. Simply reading a list of 10 items is more expensive than reading a list of 5 items. If anything, those extra "5" modules have at least that overhead cost, it's not zero. The debt financing analogy comes in to describe how high that interest rate is. Saying "code" is a cost is essentially just saying that all code has a non-zero maintenance cost (maintenance being the activity of reading, understanding, debugging, modifying, or deleting code).

deleted 3y ago

[deleted]

crazygringo 3y ago

Completely agreed. The idea that "all code is technical debt" because all requirements could hypothetically change someday, makes as much sense as saying "all currencies have no value" because 1,000 years from now we might not be using any of them. Technical debt is not defined in terms of possible future requirements, it is defined in terms of current requirements. Code that elegantly and concisely expresses current requirements is debt-free. Code that is a mix of elegantly expressing old requirements, with new requirements expressed in a hacky fast way, has debt. But trying to judge code in reference to all possible future requirements is utterly nonsensical. You can't measure that. It's literally meaningless. So no, all code is not technical debt. Technical debt is technical debt, and clean code is clean code. Trying to redefine words to mean their opposite helps no one. That way lies madness.

posix86 3y ago
But dept can only recognized if you're trying to implement something new, and notice that you have to pay interest. Poorly written code makes it very hard to implement new features & debug existing one, while well written code makes it easy. So the current dept can only be estimated with respect of features you are implementing in the future.
- majikandy 3y ago
  Seems fair to assume that “current requirements” means current roadmap of requirements. Taken to extreme, if there are no future requirements at all, there is no technical debt.

chuckadams 3y ago

My brother coined a term that I really love: "feature karma". He's an actual Buddhist, so he used the term "karma" not to mean a simple score with only positive connotations, but as something you're chained to and must work off should you at some point want to move past it.

CSMastermind 3y ago
I often try to explain the concept of Technical Wealth as the other side of the spectrum from Technical Debt. Technical Wealth pays dividends; Tech Debt charges interest on which the payments will eventually become unwieldy. That doesn't mean you shouldn't take on Technical Debt, like many startups do with real money you can and should go into debt in order to get your business off the ground. But just like irresponsible financial management can kill your company, so can irresponsible technical management.

Phiwise_ 3y ago

Absolutely agreed. Articles in this vein rather get my goat, especially because the analogy to real debt is more clear: If someone wrote a consumer finance article like "All purchases of things other than cans of beans and Certificates of Deposit are like Mortgages, because what if your industry collapses tomorrow?" most people have the good sense to complain that the usually decent advice of saving a bit for a rainy day was being way exaggerated. And yet pieces that run something like "All programming of things other than washing machine microcontrollers are like technical debt, because what if your customer's needs suddenly change entirely?" get much more play. Sure, disasters can happen, and it pays to reserve some resources to be ready for them, but it also pays to use resources when times are good to expand. It seems to me Cunningham's point was to encourage a move towards balance; headlines that don't overshoot the mark.

j45 3y ago

Well said. Too often code is a proxy for complexity being added unnecessarily, consciously or unconsciously. Premature optimization or over-engineering or burning your innovation points on shiny object syndrome can create technical debt in a different way than just taking shortcuts.

NoPicklez 3y ago

I agree and I can't stand it when people dilute terms to the point they become meaningless. I see it in other areas as well. It isn't a profound thought to take a term like "technical debt" and just say well that's just everything. Technical debt is absolutely that, adding something that incurs a level of interest, until you take the time to pay it off. In life, we often always have a level of interest to be paid. It's a good analogy

rjzzleep 3y ago
Almost ten years ago I had the unfortunate opportunity to work with a master manipulator who was unfortunately more senior in the hierarchy. Most of his code was actually technical debt. The code that wasn’t was external code he integrated. All of the code he wrote would eventually break down and until it did world force you to work around it, so it wouldn’t fail from interfacing with it. In one of the standup’s i used the term technical debt to argue for fixing one of these issues that broke later but which he discouraged everyone to fix. After that he integrated the term into his daily use to the point that it became meaningless. The people that believed this snake oil salesman thought that he had already carefully weighed his own decisions in advance. Needless to say the issue was not fixed before he left the company and cost millions and plenty of customer headaches.

ljm 3y ago

I think it could make more sense if it's rephrased to 'all code is a liability'. Then the equation is simpler. More code = more to maintain = more liability. It says nothing about the quality of the code, just the quantity. Tech debt is a trade-off between near term and long term ambitions - it is literally impossible to build a successful project without accruing this kind of debt, simply because you cannot perfectly anticipate the future. In that sense, it's not so much debt as it is a maintenance overhead.

code_biologist 3y ago
I agree with the general sentiment but would generalize to "all corporate surface area is a liability" and that liability can be minimized in many ways. An illustrative example where more code is a lesser liability: I work on a product with an activity feed feature built in 2018-19. There was a political battle on whether to build it internally or use a third party "feed as a service" product. The build it internally folks won. The "FaaS" under consideration went under during the pandemic, so we dodged that bullet. We also have customized it in ways not possible with an off the shelf product, with no big rewrite necessary. On the flipside, we've never had time to implement things that are trivial with commercial FaaS like iOS and Android push notifications. Trade-offs are hard!
opportune 3y ago
Agreed, or similarly: all software has a carrying (maintenance, but I think that has connotations of not including full ongoing TCO) cost. Code is a liability in the sense that it has a non-zero carrying cost. The ideal software implementing a given functionality has as low of a carrying cost as possible. More code, in quantity and complexity, typically means more carrying costs. One of the appeals of SAAS is that this carrying cost is easy to quantify and predict. Going further, for high-quality OSS projects like the Linux Kernel, the carrying cost may be 0 or close to 0 for most users. But lower quality OSS or buggy SAAS has a carrying cost in the form of bugs (possibly affecting downstream users), patches, need for support + back and forth. In this analogy tech debt is a tradeoff for some short term benefit (like simplicity, time to market) at the expense of higher carrying costs down the line. But some carrying costs simply can’t be reduced - you can’t mooch off something like the Linux kernel, get your own carrying costs all the way to 0, or find a SAAS provider/vendor willing to give you the software for free. So in this model not all code is technical debt.

mmcnl 3y ago

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

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

matheusmoreira 3y ago

I agree. Technical debt is a very useful concept and it's not helpful to dilute its meaning. Only a couple days ago I decided to change some data structure. It was needlessly hard because I had neglected to create an accessor function and was instead accessing it directly everywhere. Had to change every bit of code that accessed the structure's fields. That's technical debt: something the programmer should have done but for whatever reason didn't. I paid back the debt by doing it: I created the function. Now if I want to change the data structure I only have to update the function. If I hadn't paid it back, it would start accruing interest: it would be even harder in the future as more and more stuff accessed the fields.

avereveard 3y ago
No sorry that is just bad encapsulation and goes under poor programming.Technical debt occurs when you write a good program to your current understanding of the solution knowing that the full understanding of the solution will come later, and that you need to do something now to get to that learning point later, and so you have to repay your partial understanding at the beginning with refactoring later. Here, heed Ward words directly, poor programming is not debt, and debt doesn't cover "whatever reason programmer may have" but has a specific well defined scope: https://m.youtube.com/watch?v=pqeJFYwnkjE&t=198 https://m.youtube.com/watch?v=pqeJFYwnkjE&t=198
- jimmaswell 3y ago
  That's certainly not how most people understand the term.
  - avereveard 3y ago
    I mean that is the guy who invented it should we just go "ah well the uneducated masses really wish for a term that excuses bad programming so let's twist this nice metaphor into something we can sell to management to that effect", or instead just get the quote and correct people whenever we can until there's no more shadow under which to hide bad code.
- 3y ago

wredue 3y ago

I especially likes the discussion of “adding assumptions” where it became readily apparent that there was zero experience guiding anything in their product, and when they said “assumption”, what they actually meant was “completely and utterly devoid of any semblance of planning what-so-ever”

Aeolun 3y ago

> The analogy is that some of your development is going to be wasted "servicing the debt" going forward until you fix that (pay off the debt). This is the same for bog standard development though. Any code you add, regardless of whether it is termed technical debt or not, will make your future development slower. Like you say, that doesn’t mean it’s the wrong move, you want to build a product after all, but I think I can see where the author comes from.

seanhunter 3y ago
That's not true at all. There are lots of circumstances where adding (good) code adds velocity. Imagine I'm trying to do a bunch of graphics stuff. The code I write to integrate a 3rd party graphics library will make my future development faster. I am effectively creating a lever I will later use to increase my productivity. Say I need to do a bunch of linear algebra. Code I write to calculate dot products, determinants etc (or better yet to use a library to do those things) will greatly accellerate progress later and enable me to think in terms of the linear transformations I'm trying to accomplish rather than the underlying primitive operations.