5 ms·

> Technical debt, as originally coined by Ward Cunningham, is the idea that you can gain a temporary speed boost by rushing software development, at the cost of

by tomxor 3y ago

> Technical debt, as originally coined by Ward Cunningham, is the idea that you can gain a temporary speed boost by rushing software development, at the cost of slowing down future development. No! Ward's blog post linked in this very paragraph [0] describes the original definition quite clearly, and it's not this. The term was originally intended to describe the delta between a programmer's current understanding acquired through the process of developing the software, and the accumulated implementation which is based upon a combination of past understanding. Because writing a program is often a process of discovery and learning about the problem and solution space, it's not usually possible to write the ideal implementation up front. It's quite clear In Ward's 2nd paragraph where he describes the correction of this debt: > it was important to me that we accumulate the learnings we did about the application over time by modifying the program to look as if we had known what we were doing all along and to look as if it had been easy to do in Smalltalk. What the author is describing is the modern definition that it has acquired independently, where by programmers knowingly take shortcuts... this is an entirely different phenomenon, intentionally writing code in a way that is less than ideal even based on current understanding. I find the original definition far more interesting and insightful, but the modern one is perhaps more reflective of the more common realities of the pressure developing software in a business today. [0] https://wiki.c2.com/?WardExplainsDebtMetaphor https://wiki.c2.com/?WardExplainsDebtMetaphor [edit] Despite this error, I do agree with the sentiment of the article, that too much code is a liability, that features can cost more than they are worth. Ward's definition of technical debt affects the cohesion and correctness of the code, the idea that if you could tear it all up every day and re-write it from scratch that it would always reflect the most up to date understanding, and for moving targets the most up to date problem, that it be absent of the weight of past misconceptions or solutions to past problems... aiming for minimal code makes achieving that state far more viable - these are complementary insights, so it's a shame the nuance of the original definition was lost.

0xdeadbeefbabe 3y ago
I had no idea Cunningham was so thoughtful about it. It's a term used by less thoughtful people in most of my experience.
- nirvdrum 3y ago
  I think something similar happened with the term "refactoring." While it had been in use by a small community beforehand, Fowler's "Refactoring" book is what really opened it up to a wider audience. The book defines refactoring as: "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written." The book then goes on to describe the methodology and runs through common refactorings step-by-step. Nowadays the term is used almost generically for code improvement. I'll see commit messages like "refactored the API", which violates the edict to not alter external behavior. Languages evolve and so on, but it's remarkable to me how quickly precisely defined terms (or even new words) change their meaning in tech. My cynical take is it's easier to get management to buy into "assuming technical debt" and addressing it with a "refactor" later than it is to "cut corners" and "rewrite" the code later. As long as everyone understands the new definition I guess there isn't even anything wrong with it, but it's a shame we've then lost a term for the original meaning.
  - wavemode 3y ago
    > Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. That's the meaning of refactoring that I typically hear, tbh. I guess it just depends on what one means by "external behavior". Changing a function signature changes the external behavior of that function for callers of that function, but not for other modules. Changing the interface of a module changes its external behavior for other modules depending on it, but not for clients of the whole server. Changing an API changes the external behavior for the client, but not for the end user (to whom API changes are invisible and irrelevant). Traditionally, one might say "if the tests still pass, it was a refactor." Though nowadays that's probably not true either, as business code tends to contain a lot more internal testing than it used to (which is good! but also bad).
    - nirvdrum 3y ago
ska 3y ago
I agree with this history, but don't think the meaning was acquired independently so much as naturally grew. Ward presents it in a sort of "optimal development" context, where what we did last year was the right thing last year, but we know more now/things have changed and we know what the right thing would be today. This is definitely happens, but doesn't allow for a lot of other real-world reasons for this mismatch between the current and ideal state. The effect is the roughly the same though, there is an impedance mismatch between what you want to do to/with the system today, and what the system actual is today, and that has a cost. The work of reducing this impedance is real work, and can be thought of as "paying off debt".
- zoogeny 3y ago
  > there is an impedance mismatch between what you want to do to/with the system today, and what the system actual is today This is a better conceptualization compared to the idea that tech-debt is the result of shortcuts or rushed code. Tech debt arises for a lot of reasons, including shortcuts but not exclusively because of shortcuts. I've seen tech debt arise because well-meaning engineers were trying to do things "the right way". I think it is just a kind of entropy thing that we have to fight against. A lot of confounding factors lead to code that is hard to maintain and extend. I think it is an unfair characterization to suggest it is solely because of laziness or negligence.
  - ska 3y ago
    I've used the entropy analogy also. In particular, entropy always wins in the end. But I do think it weakens the "debt" analogy to consider it the same thing, because I like the idea that this is sometimes transactional - a choice you make for benefit now which has amortized cost. I think this is a valuable idea that is separable from the problems of complexity growth, entropy, etc. I certainly don't agree with the idea that all technical debt is due to shoddy work, that's obviously silly. I suspect that people fall into it because it is easy to understand. The original framing is more nuanced and harder to think about but no less in effect.
  - gav 3y ago
    To generalize that idea a little, I think about technical debt being the accumulation of less-than-perfect decisions, if you consider the decision you made against the best possible decision that could have been made in hindsight. Sometimes that's not making things flexible enough, or too flexible, or not having all the requirements captured, or making technical bets that didn't pan out.
burningChrome 3y ago
This is how the author starts his entire post. I would assume if he misinterpreted Cunningham's original idea, would it then follow that the rest of the article is suspect considering the original premise is so far off from what Cunningham originally intended?
lysecret 3y ago
Indeed very insightful thanks for sharing.
worldsayshi 3y ago
In other words, technical debt is when parts of the system does not yet implement the abstractions that align with the developers understanding of the problem? While I don't think we're there yet or maybe not even close, I kind of feel like this kind of technical debt would be something that an LLM should be able to help with. Why can't I point to a piece of code and say "Look at this new code I wrote, now go and refactor the rest of the code base to align with it." Or can I? I assume if I tried to implement something that did this I would hit the context size limit and that would be it.
jahewson 3y ago
In hindsight Ward’s choice of the word “debt” may not have been the right one. It feels more like “legacy code”, in that there was nothing wrong with it at the time. Its impact on newer parts of the system is to create a “legacy burden”. Of course if there was something wrong with the code at the time then it’s more of a “proficiency debt” (or burden) where the shortcut taken was not in the coding but in not reading the docs and practicing the craft.
- nighthawk454 3y ago
  yeah sounds more like "design lag", where the software necessarily lags behind your ideal understanding by some amount
tshaddox 3y ago
From what I can tell, the definition in the link you provided is precisely what you're saying it's not. He says this: > The explanation I gave to my boss, and this was financial software, was a financial analogy I called "the debt metaphor". And that said that if we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were gonna continually stumble over that disagreement and that would slow us down which was like paying interest on a loan. So indeed, his definition of technical debt is explicitly that by rushing software development now you will slow down future development. The specific software engineering task that caused him to develop the analogy was about rewriting some code to incorporate new learnings, but the analogy itself is clearly applicable to any software engineering task that could be deferred to the future (with a cost).
- djur 3y ago
  Right, and I think the example here is instructive. He's not talking about rushed, shoddy, buggy code. He's talking about not taking the time to implement the right design. The resulting code might work just fine and doesn't necessarily impose additional maintenance costs, but the design issues mean that every time you're adding or modifying a feature you have to do extra work to translate from the 'correct' theoretical design of the feature to the actual design. Unfortunately, while managers are often happy with "it'll make page load faster" or "it'll increase uptime" as a justification for a project, and "it'll reduce bug reports" and even sometimes "it'll automate manual tasks", "it'll make development easier" can be a really hard sell. It sounds pretty abstract and I think some managers start to think that it's just an excuse. It's certainly hard to quantify the impact, especially if you're expected to do that in $/yr.
turtlebits 3y ago
IME being in the operations space for along time, developers often oversimplify/ignore non-coding tasks, that is where I find most tech debt comes from, as the time/resources is not estimated/allocated ahead of time. Corner cutting == tech debt Ask any ops person and none of them will tell you they're content with the state of their infrastructure.
drewcoo 3y ago
> the modern definition that it has acquired independently, where by programmers knowingly take shortcuts No error! That seems to be included in this summary, which Cunningham reviewed: https://www.agilealliance.org/wp-content/uploads/2016/05/IntroductiontotheTechnicalDebtConcept-V-02.pdf https://www.agilealliance.org/wp-content/uploads/2016/05/Int... Quoth the PDF: > When taking short cuts and delivering code that is not quite right for the programming task of the moment, a development team incurs Technical Debt.

by tomxor 3y ago

0xdeadbeefbabe 3y ago

I had no idea Cunningham was so thoughtful about it. It's a term used by less thoughtful people in most of my experience.

nirvdrum 3y ago
I think something similar happened with the term "refactoring." While it had been in use by a small community beforehand, Fowler's "Refactoring" book is what really opened it up to a wider audience. The book defines refactoring as: "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written." The book then goes on to describe the methodology and runs through common refactorings step-by-step. Nowadays the term is used almost generically for code improvement. I'll see commit messages like "refactored the API", which violates the edict to not alter external behavior. Languages evolve and so on, but it's remarkable to me how quickly precisely defined terms (or even new words) change their meaning in tech. My cynical take is it's easier to get management to buy into "assuming technical debt" and addressing it with a "refactor" later than it is to "cut corners" and "rewrite" the code later. As long as everyone understands the new definition I guess there isn't even anything wrong with it, but it's a shame we've then lost a term for the original meaning.
- wavemode 3y ago
  > Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. That's the meaning of refactoring that I typically hear, tbh. I guess it just depends on what one means by "external behavior". Changing a function signature changes the external behavior of that function for callers of that function, but not for other modules. Changing the interface of a module changes its external behavior for other modules depending on it, but not for clients of the whole server. Changing an API changes the external behavior for the client, but not for the end user (to whom API changes are invisible and irrelevant). Traditionally, one might say "if the tests still pass, it was a refactor." Though nowadays that's probably not true either, as business code tends to contain a lot more internal testing than it used to (which is good! but also bad).
  - nirvdrum 3y ago

ska 3y ago

I agree with this history, but don't think the meaning was acquired independently so much as naturally grew. Ward presents it in a sort of "optimal development" context, where what we did last year was the right thing last year, but we know more now/things have changed and we know what the right thing would be today. This is definitely happens, but doesn't allow for a lot of other real-world reasons for this mismatch between the current and ideal state. The effect is the roughly the same though, there is an impedance mismatch between what you want to do to/with the system today, and what the system actual is today, and that has a cost. The work of reducing this impedance is real work, and can be thought of as "paying off debt".

zoogeny 3y ago
> there is an impedance mismatch between what you want to do to/with the system today, and what the system actual is today This is a better conceptualization compared to the idea that tech-debt is the result of shortcuts or rushed code. Tech debt arises for a lot of reasons, including shortcuts but not exclusively because of shortcuts. I've seen tech debt arise because well-meaning engineers were trying to do things "the right way". I think it is just a kind of entropy thing that we have to fight against. A lot of confounding factors lead to code that is hard to maintain and extend. I think it is an unfair characterization to suggest it is solely because of laziness or negligence.
- ska 3y ago
  I've used the entropy analogy also. In particular, entropy always wins in the end. But I do think it weakens the "debt" analogy to consider it the same thing, because I like the idea that this is sometimes transactional - a choice you make for benefit now which has amortized cost. I think this is a valuable idea that is separable from the problems of complexity growth, entropy, etc. I certainly don't agree with the idea that all technical debt is due to shoddy work, that's obviously silly. I suspect that people fall into it because it is easy to understand. The original framing is more nuanced and harder to think about but no less in effect.
- gav 3y ago
  To generalize that idea a little, I think about technical debt being the accumulation of less-than-perfect decisions, if you consider the decision you made against the best possible decision that could have been made in hindsight. Sometimes that's not making things flexible enough, or too flexible, or not having all the requirements captured, or making technical bets that didn't pan out.

burningChrome 3y ago

This is how the author starts his entire post. I would assume if he misinterpreted Cunningham's original idea, would it then follow that the rest of the article is suspect considering the original premise is so far off from what Cunningham originally intended?

lysecret 3y ago

Indeed very insightful thanks for sharing.

worldsayshi 3y ago

In other words, technical debt is when parts of the system does not yet implement the abstractions that align with the developers understanding of the problem? While I don't think we're there yet or maybe not even close, I kind of feel like this kind of technical debt would be something that an LLM should be able to help with. Why can't I point to a piece of code and say "Look at this new code I wrote, now go and refactor the rest of the code base to align with it." Or can I? I assume if I tried to implement something that did this I would hit the context size limit and that would be it.

jahewson 3y ago

In hindsight Ward’s choice of the word “debt” may not have been the right one. It feels more like “legacy code”, in that there was nothing wrong with it at the time. Its impact on newer parts of the system is to create a “legacy burden”. Of course if there was something wrong with the code at the time then it’s more of a “proficiency debt” (or burden) where the shortcut taken was not in the coding but in not reading the docs and practicing the craft.

nighthawk454 3y ago
yeah sounds more like "design lag", where the software necessarily lags behind your ideal understanding by some amount

tshaddox 3y ago

From what I can tell, the definition in the link you provided is precisely what you're saying it's not. He says this: > The explanation I gave to my boss, and this was financial software, was a financial analogy I called "the debt metaphor". And that said that if we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were gonna continually stumble over that disagreement and that would slow us down which was like paying interest on a loan. So indeed, his definition of technical debt is explicitly that by rushing software development now you will slow down future development. The specific software engineering task that caused him to develop the analogy was about rewriting some code to incorporate new learnings, but the analogy itself is clearly applicable to any software engineering task that could be deferred to the future (with a cost).

djur 3y ago
Right, and I think the example here is instructive. He's not talking about rushed, shoddy, buggy code. He's talking about not taking the time to implement the right design. The resulting code might work just fine and doesn't necessarily impose additional maintenance costs, but the design issues mean that every time you're adding or modifying a feature you have to do extra work to translate from the 'correct' theoretical design of the feature to the actual design. Unfortunately, while managers are often happy with "it'll make page load faster" or "it'll increase uptime" as a justification for a project, and "it'll reduce bug reports" and even sometimes "it'll automate manual tasks", "it'll make development easier" can be a really hard sell. It sounds pretty abstract and I think some managers start to think that it's just an excuse. It's certainly hard to quantify the impact, especially if you're expected to do that in $/yr.

turtlebits 3y ago

IME being in the operations space for along time, developers often oversimplify/ignore non-coding tasks, that is where I find most tech debt comes from, as the time/resources is not estimated/allocated ahead of time. Corner cutting == tech debt Ask any ops person and none of them will tell you they're content with the state of their infrastructure.

drewcoo 3y ago

> the modern definition that it has acquired independently, where by programmers knowingly take shortcuts No error! That seems to be included in this summary, which Cunningham reviewed: https://www.agilealliance.org/wp-content/uploads/2016/05/IntroductiontotheTechnicalDebtConcept-V-02.pdf https://www.agilealliance.org/wp-content/uploads/2016/05/Int... Quoth the PDF: > When taking short cuts and delivering code that is not quite right for the programming task of the moment, a development team incurs Technical Debt.