Ur-Technical Debt
georgefairbanks.com
georgefairbanks.com
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.
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.
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"
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!".
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.
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.
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":
https://stackoverflow.com/questions/581426/why-is-a-c-vector....
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”.
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.
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.
Tomorrow it's tech debt that's causing you problems.
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.
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.
So the technical debt is subject to technical debt.
https://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffal...
technical technical technical.....debt does.
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.
In UK, it's like tour or fur.
Just for the sake of non-native speakers like me... My first idea was "your-technical debt" :)
Edit source: https://en.wiktionary.org/wiki/ur-
A German prefix, so my guess would be however you would pronounce "oor" as in "boor" but not "oor" as in "floor" :)
https://en.wiktionary.org/wiki/ur-, says it’s
- (UK) IPA(key): /ʊə/, /ɜː/
- (US) IPA(key): /ɝ/
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.
https://louwrentius.com/most-technical-debt-is-just-bullshit...
> 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.
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.