4 ms·

Do people really mislabel tech debt? Based on the original metaphor[0], I think we're doing okay. To be contrarian, even if we aren't getting it exactly right

Do people really mislabel tech debt? Based on the original metaphor[0], I think we're doing okay. To be contrarian, even if we aren't getting it exactly right - is it so bad? Engineers generally understand it's that "something"/"elephant-in-room" that starts showing up as a program grows, gets utilized. When adding new features is taking on a complexity that's not inherent to the feature, but grown because of the way it or the system been engineered/architected. It's this qualitative gap between ideal and reality. When it becomes too large, you're spending time fighting a complexity that ideally shouldn't be there. Unlike true debt, it's qualitative - much like a credit score. [0] http://wiki.c2.com/?WardExplainsDebtMetaphor http://wiki.c2.com/?WardExplainsDebtMetaphor

kubanczyk 6y ago
It's down, so: https://web.archive.org/web/20200930101416/http://wiki.c2.com/?WardExplainsDebtMetaphor https://web.archive.org/web/20200930101416/http://wiki.c2.co... There, the original metaphor is exactly what the OP refers to: > if we failed to make our program align with what we then understood This wouldn't be even considered tech debt in many projects today. It is code that has been well done, according to all project's standards except just for one point: it only partially incorporates our current understanding of the problem domain. When some enlightenment moment happens in a project, the contributors are usually split: - some either understand the new idea or want to understand it, - some shrug it off or even explicitly reject it. Cleaning up this kind of debt will harm the work of the latter for a time. So it's decidedly a different decision than refactoring an obvious big-ball-o-mud (the code which is not properly mapping anyone's ideas). The discussions can be heated, and so naming/popularizing the idea is beneficial.
jasode 6y ago
>Do people really mislabel tech debt? The most common way I see "technical debt" used is: deliberately code a quick & dirty low-quality-short-term fix to address an immediate problem and we know we'll have to clean this up later for a high-quality-long-term solution that's easier to maintain. This differs from Ward Cunningham's idea of future unknowable specs not aligning with yesterday's code. >To be contrarian, even if we aren't getting it exactly right - is it so bad? IMO, it's not so bad. A lot of short and snappy terminology gets a life of its own that doesn't match the original meaning. Examples: - "worse is better" is typically used very differently from Richard Gabriel's original usage - "object-oriented" as popularized by C++/C# (static binding at compile time as default) is different than Alan Kay's original definition (dynamic extreme late binding) - "REST" as "API endpoint as url" is used differently than Roy Fielding's paper of Representational State Transfer (http itself exposes the navigation & discovery of system capabilities) Since most people discussing <any_topic> are not going to rigorously research the precise etymology of a term, the popular meanings can drift away from original usage. Today, politicians use the word "liberal" differently than its earlier associations with "economic freedom"
- pydry 6y ago
  >The most common way I see "technical debt" used is: deliberately code a quick & dirty low-quality-short-term fix to address an immediate problem and we know we'll have to clean this up later for a high-quality-long-term solution that's easier to maintain. I see this, but I also see all sorts of other things bundled in with it including: * Code that was written by less skilled developers * Code that isn't necessarily harder to maintain, but is written with a different sense of aesthetics. * Infrastructure problems * Code that the reader doesn't understand I've almost never seen the origins of the code considered relevant when identifying technical debt either. People don't go "was this deliberately quick and dirty? no? ok, then it's not technical debt". They look at code or work with it and get frustrated and think "TECH DEBT!".
- rietta 6y ago
  Too often "we'll have to clean this up later for a high-quality-long-term solution that's easier to maintain" is never cleaned up until the company fails and the entire system is thrown away/replaced. The lack of investment in improving vs adding can be discouraging.
darkerside 6y ago
I don't think it's necessary bad, but I value specificity of language as any good engineer should. If you are able to differentiate between different types of problems more effectively (discrepancy between abstraction and implementation, versus simple growth in complexity, versus code missing consistent defensive safeguards), you will be better able to rectify the problem at hand, instead of getting frustrated at a team who is doing their best, but continues to have "inefficiency due to all this tech debt".

kubanczyk 6y ago

It's down, so: https://web.archive.org/web/20200930101416/http://wiki.c2.com/?WardExplainsDebtMetaphor https://web.archive.org/web/20200930101416/http://wiki.c2.co... There, the original metaphor is exactly what the OP refers to: > if we failed to make our program align with what we then understood This wouldn't be even considered tech debt in many projects today. It is code that has been well done, according to all project's standards except just for one point: it only partially incorporates our current understanding of the problem domain. When some enlightenment moment happens in a project, the contributors are usually split: - some either understand the new idea or want to understand it, - some shrug it off or even explicitly reject it. Cleaning up this kind of debt will harm the work of the latter for a time. So it's decidedly a different decision than refactoring an obvious big-ball-o-mud (the code which is not properly mapping anyone's ideas). The discussions can be heated, and so naming/popularizing the idea is beneficial.

jasode 6y ago

>Do people really mislabel tech debt? The most common way I see "technical debt" used is: deliberately code a quick & dirty low-quality-short-term fix to address an immediate problem and we know we'll have to clean this up later for a high-quality-long-term solution that's easier to maintain. This differs from Ward Cunningham's idea of future unknowable specs not aligning with yesterday's code. >To be contrarian, even if we aren't getting it exactly right - is it so bad? IMO, it's not so bad. A lot of short and snappy terminology gets a life of its own that doesn't match the original meaning. Examples: - "worse is better" is typically used very differently from Richard Gabriel's original usage - "object-oriented" as popularized by C++/C# (static binding at compile time as default) is different than Alan Kay's original definition (dynamic extreme late binding) - "REST" as "API endpoint as url" is used differently than Roy Fielding's paper of Representational State Transfer (http itself exposes the navigation & discovery of system capabilities) Since most people discussing <any_topic> are not going to rigorously research the precise etymology of a term, the popular meanings can drift away from original usage. Today, politicians use the word "liberal" differently than its earlier associations with "economic freedom"

pydry 6y ago
>The most common way I see "technical debt" used is: deliberately code a quick & dirty low-quality-short-term fix to address an immediate problem and we know we'll have to clean this up later for a high-quality-long-term solution that's easier to maintain. I see this, but I also see all sorts of other things bundled in with it including: * Code that was written by less skilled developers * Code that isn't necessarily harder to maintain, but is written with a different sense of aesthetics. * Infrastructure problems * Code that the reader doesn't understand I've almost never seen the origins of the code considered relevant when identifying technical debt either. People don't go "was this deliberately quick and dirty? no? ok, then it's not technical debt". They look at code or work with it and get frustrated and think "TECH DEBT!".
rietta 6y ago
Too often "we'll have to clean this up later for a high-quality-long-term solution that's easier to maintain" is never cleaned up until the company fails and the entire system is thrown away/replaced. The lack of investment in improving vs adding can be discouraging.

darkerside 6y ago

I don't think it's necessary bad, but I value specificity of language as any good engineer should. If you are able to differentiate between different types of problems more effectively (discrepancy between abstraction and implementation, versus simple growth in complexity, versus code missing consistent defensive safeguards), you will be better able to rectify the problem at hand, instead of getting frustrated at a team who is doing their best, but continues to have "inefficiency due to all this tech debt".