[HN Gopher] Technical Debt Is a Myth
___________________________________________________________________
Technical Debt Is a Myth
Author : gcoleman
Score : 11 points
Date : 2022-11-07 20:29 UTC (2 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| xupybd wrote:
| "Taking out an organisational mortgage should be a deliberate
| choices. It has costs, interest, pros, and cons."
|
| I could not agree more.
| PaulHoule wrote:
| It seems like they are trying to do otherwise but I see this
| article as perpetuating the basic problem with "technical debt"
| which is the analogy with debt. But what do you expect from an
| article on Medium?
|
| If you take on debt the bank is going to question if you can
| pay it. You're going to have to go through a formal process and
| bring in expensive experts such as accountants to justify that
| taking on debt is worthwhile.
|
| Most "technical debt" is blundered into out of ignorance.
| Nobody sits down and thinks "we can save two hours now at the
| cost of three hours later" because it would probably take four
| hours to do the calculation. Sometimes it really is like that
| but frequently it is like "we can save two hours now at the
| cost of of two months later", such as when people make an
| incorrect database design that involves cleaning up corrupt
| data later on. Cases like that dominate the cost of "technical
| debt" to the point where the 2 hours now, 3 hours later cases
| just don't matter.
| postalrat wrote:
| We SPEND 2 hours today to possibly save 3 hours in a few
| years.
|
| We SPEND 2 hours today to possibly save 3 hours in a few
| years.
|
| We SPEND 2 hours today to possibly save 3 hours in a few
| years.
|
| We SPEND 2 hours today to possibly save 3 hours in a few
| years.
|
| We SPEND 2 hours today to possibly save 3 hours in a few
| years.
|
| We SPEND 2 hours today to possibly save 3 hours in a few
| years.
|
| Oops, we just found a better way and all the code is gone.
| wizofaus wrote:
| > Nobody sits down and thinks "we can save two hours now at
| the cost of three hours later"
|
| Perhaps not, but there're plenty of times you realise the
| "proper" solution that's going to leave you with well-
| structured code that's easy to maintain and easy to extend to
| likely future functionality is going to take weeks, whereas a
| quick'n'dirty solution that will get a bug fixed or an MVP-
| version of a feature implemented could be done in a few
| hours, and the latter option makes sense even from a
| technical POV because there's little certainty that the extra
| effort will pay off (esp. if it involves higher risk of
| breaking existing functionality, which is often the case).
| Unfortunately it's the accumulation of such decisions and
| lack of time to go back and revise decisions/rewrite code
| that lead to unwieldy and bug-ridden codebases.
| yunwal wrote:
| Isn't the point of using the phrase "technical debt" that you
| _should_ be doing this? It's an idealistic phrase, not one
| that's supposed to apply to every organization.
| PaulHoule wrote:
| I rarely hear "technical debt" in the context of "let's
| incur some technical debt now so we can deliver this ticket
| quickly", it's rather "we can't deliver this ticket quickly
| now because somebody (usually somebody else) incurred
| technical debt" in the past.
|
| If management is using it usually an attempt to shut
| discussion down in the context of (i) poor psychological
| safety on the part of devs because (ii) management doesn't
| trust anything the devs say because (iii) management knows
| that the devs are reading cargo-cult blog posts like "if
| this software was written in Haskell it wouldn't have any
| bugs".
| iLoveOncall wrote:
| I'm not sure what what to think of the article because I think
| the definition he chose for technical debt is extremely
| reductive.
|
| No, technical debt does not only come from taking shortcuts. I
| would even go as far as saying that most of the time it does not
| come from taking shortcuts.
|
| - You wrote a perfectly engineered system in Cobold 30 years ago
| that was state of the art then? Well, now all your Cobold
| developers have retired and you need to add new features to that
| tool. It's tech debt.
|
| - Your tool was built to support 100 users but now it needs to
| support 100M? It's tech debt.
|
| - You were getting some data from the Google Stadia API? Tech
| debt.
|
| - You're using a library that just got an important security
| update? Tech debt.
|
| As another commenter pointed out, the term "debt" was wrongly
| chosen. It's not debt. It's stuff that used to be perfectly fine
| and due to no fault of yours is not anymore.
| pixl97 wrote:
| Technical entropy.
|
| Entropy is unavoidable is the outcome of any work occurring.
| tqi wrote:
| > When we use the term technical debt, lots of non-technical
| people hear, 'This is a technical problem, with technical
| solutions.' This thinking couldn't be further from the truth. If
| the organisation is responsible for the creation of the debt (as
| established above), it's also responsible for the elimination of
| it. Debt belongs to the entire organisation.
|
| This is a strawman.
___________________________________________________________________
(page generated 2022-11-07 23:02 UTC)