4 ms·

>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 addre

by 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.

by jasode 6y ago

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.