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.
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"
>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!".
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.
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.
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".
Watching the video, I'm not sure I interpret it to say the term technical refers only to code needing to be refactored because it was well written but based on incomplete knowledge. But I understand how someone could interpret the video differently.
In the video he tells how he used the term to explain to his boss why they wanted to spend time refactoring code. He justfies what they did as borrowing money to make an investment. They had to pay off the loan but he thinks this was a good investment.
The specific section where he talks about people getting something wrong related to the debt metaphor at 3:18, the section title "Agility". If you just watch this, it can seem like he is saying they are using the term wrong. But I think what he is saying is that they are getting the _justification_ for going into technical debt wrong, not that they are using the term technical debt wrong. After he calls it a metaphor, not a term.
In other words, I think it is OK to use the term technical debt to refer to "debt" no matter how it is incurred.
I understand people could interpret the video differently and I would be interested in hearing other interpretations.
In my opinion: If a term is starting to be mis-used, the correct solution isn't to invent a new term that means what it originally did. The correct solution is to teach people not to mis-use it.
We have had plenty of words that have drifted in meaning, only to be replaced by a new word that means exactly the same thing as the original word originally meant. There are several circumstances that cause this to happen. One is if the meaning of the word is mis-understood. There isn't any reason to believe that the replacement word will be any better-understood, so it will likely drift in meaning as well. Another is if the word becomes seen as offensive in some way. Then a new word replaces it with the intention of meaning the same thing, but in a non-offensive manner (which the original word originally had anyway). The new word will also soon afterwards become seen as offensive, and another replacement will have to be introduced.
It would be much less confusing if words just kept meaning the same thing.
>The correct solution is to teach people not to mis-use it. [...] It would be much less confusing if words just kept meaning the same thing.
Your recommendation is impossible to implement because language usage is decentralized.
The growing number of humans that can mis-use a term outpace the smaller force of volunteer "language police" that try to correct people.
E.g. It didn't matter that quad-copter enthusiasts kept trying to educate the public that DJI toys should not be called "drones". That battle has been lost and the the term "drone" has won over alternatives such as "remote quadcopter" or "UAV". It's like shouting into a hurricane.
Even very well-educated people mis-use terms. Alex Stepanov inadvertently misused "vector" when creating STL. C++ std::vector should have been called "vararray" and std::array should have been called "vector":
>The correct solution is to teach people not to mis-use it.
I like where you’re coming from, but much of the time leveraging ambiguous terms is exactly the point. People prioritize results over clarity of communication.
Most of it is done unconsciously rather than maliciously. Spend a few days carefully watching everything you hear and ask yourself if the speaker/writer is prioritizing clear communication or just using concepts as magic incantations for “I’m right”.
People get very attached to their meanings and very resistant to having redefinitions "imposed" upon them.
Inventing new terms avoids all that baggage.
There is also reason to believe that a replacement term will be less misunderstood if it is more precisely defined than the original.
The words that have the most "drift" are ones with emotional baggage attached. "Socialism" or "Capitalism" has baggage and drift. "Technical debt" does too. "Carbon" and "differential equation" do not. "Coupling" does not.
well that's nice and all but obviously 'expedient technical hacking' or any other term for where you do a less than correct fix in order to gain some temporary benefit now is a much better fit for the analogy of taking out debt than something where you thought something worked one way but as you grow in wisdom you realize there are better solutions.
I mean basically this article convinced me that the term 'technical debt', while an evocative term, is not really a great fit for the concept that it was originally meant to convey.
I agree, but only in that your new analogy is even better, not that the original analogy was flawed.
Maybe yours is more similar to typical consumer credit card debt. People make an early decision to acquire a good or service, and know they will need to pay for it down the road.
Original tech debt is more like leasing a car. You are making regular payments on something for benefit, with the knowledge that you aren't investing in the perfect solution, and at some point, you will either need to buy the car or surrender it to the dealership.
I think the original analogy is more appropriate to some sort of investment strategy, you don't know how all your investments will pan out - you have insufficient knowledge - as you go on you get more knowledge and you need to readjust your portfolio. Sometimes that means bringing in new investments and cleaning out old.
That analogy however does not work well with the idea of paying down debt etc. Because paying down debt is drawn out process with a clear result and changing your investments is probably not as drawn out and the result is still somewhat up in the air.
In conclusion, analogies are a land of contrasts of varying applicability.
Of course nobody cares that much if the maximum length of a sentence in English using only two words can be infinite if one already knows that the maximum length of a sentence in English using only one word can be infinite.
English has enormous variation in pronunciation, but I think (drawing from knowledge of German, more than of English) it’s more like “oer” in “boer” (/bʊər/ , https://en.wikipedia.org/wiki/Boer), with a somewhat shortened “oe”.
The font I'm seeing in the mono is not making this obvious: The US version has a hook on the right side. It might show up better in proportional font. /ɝ/ That hook is indicating that the vowel is rhotic aka "r-colored".
It seems to me that whether the distinction this article makes is necessary depends on what angle you view the situation from.
When looking at how you introduce technical debt, it matters a lot. The kind of technical debt Cunningham talks about is inevitable with any kind of iterative development. In contrast, the shortcuts, hacks and mistakes that normally get called technical debt can be minimized by taking some time up-front.
But from the perspective of paying down technical debt, I'm not sure it matters as much. The code has features that will continue to slowly cost you time and energy until you fix them. It doesn't matter why they were introduced.
The author's point that Cunningham's form of technical debt won't appear in any kind of static analysis is still a nice observation.
This article touches exactly the same points as the OP, it's just more direct. Only the conclusion is that because "technical debt" is widely misused, we shouldn't even use that name anymore:
> With all due respect to Cunningham, because the concept is so widely misunderstood and abused, it may be better to retire it.
But Cunningham's observation is still real, so now it's in a need for a good name.
Summarizing the article (?) I wonder whether there’s a way to split this concept of technical debt into two axes.
If you do waterfall, your code is technically “simple”, because it has a nice architecture, but it’s “misaligned”- it won’t fit the problem well because it hasn’t been tested. This seems like the ur technical debt.
If you code to solve every problem as fast as possible and patch/rip it up to stay close to the domain- now your code is complex/ugly because design philosophy has been neglected, but it’s well aligned to the problem, call that modern tech debt.
So you have two axes, ugliness/beauty and misalignment/“fit”. Modern practice says to focus on iterating fit quickly then more occasionally solve beauty, in big steps. So aesthetic debt vs alignment debt.
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