Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical debt is not debt; it’s not even technical

markgreville.ie

Post reply on HN
Print view View original

31–40 of 147 posts

Re: Technical debt is not debt; it’s not even technical

#31

Post by ggm »

As a believer in tech debt the centrepiece of my disagreements with non believers does go to the nature of debt and interest: they don't believe you accrue any extra burden delaying work to the end. I do: the accumulation of technical delay, imposes additional costs which would not have existed had you amortised the update across time. Complexity, tooling, shifts in underlying dependencies all become worse the more generations against "current" you have to transit.

It rarely costs less to delay tech work. It often costs more. The "moral force" of the debt analogy is strong.

Re: Technical debt is not debt; it’s not even technical

#32

Post by stared »

theamk wrote: post #3

I agree with general sentiment that people mean different things by "technical debt" but don't buy the argument for the title. Article says: "Debt repayment has three properties that are straightforward to grasp — principal amount, interest rate, and term [...] when comparing technical debt, there is no agreement on the principal, [...] there is no concept of an interest rate [...] , term length isn’t a fixed concept…

"Interest rate" have also another one meaning in "technical debt".

Even if you don't touch the code at all, it loses its value.

- Developers forget why did they make particular choices, and what were the implications.

- Technologies do age, and there will be maintenance cost for updating that.

Re: Technical debt is not debt; it’s not even technical

#33

Post by rorykoehler »

fsloth wrote: post #24
charles_f wrote: post #10

A) big part of the article is about the fact that the current tribal meaning of the term deviated from the meaning that the first person to use it had. This is somewhat of a semantics argument, like "hey you're using that in a commonly accepted way but Ward C didn't mean that so you're wrong". B) article points that you're accumulating debt to get speed to market or because of incomplete knowledge of the market at so…

I don't disagree with the article, and I don't disagree with you - I'm more of expanding the ideas you discussed. I think the key here is indeed that technical debt should not be used as an excuse to write poor code. But I think it may be hard to systematically tell apart code that was written intentionally fast and poorly, and code that just was written to explore the market. It "is accepted" that the most of the co…

It's not poor code it's just code that prioritises shipping now over writing for some hypothetical future state.

Re: Technical debt is not debt; it’s not even technical

#35

Post by dub »

Much of the time "technical debt" seems to be a euphemism for bad engineering

The leaning Millennium Tower in SF cost over >$100m dollars to fix. We call that a mistake or an oversight, not "engineering debt"

In software we'd have called it "technical debt", as if spending $600m to build a system that doesn't work and needs to be fixed at tremendous cost while wiping out all of the profits was somehow part of our business strategy all along.

Re: Technical debt is not debt; it’s not even technical

#36

Post by [deleted] »

razeonex wrote: post #2

I'm not particularly fan of one person coining a term and have everybody agree on that, I think every team should create its own glossary of terms and always compare against different authors that may have gone deeper analyzing a given topic. There are some terminology that makes sense for some contexts and other that simply not. It may make sense for me to call something in a certain way because my team understands…

[deleted]

Re: Technical debt is not debt; it’s not even technical

#37

Post by Closi »

dub wrote: post #35

Much of the time "technical debt" seems to be a euphemism for bad engineering The leaning Millennium Tower in SF cost over >$100m dollars to fix. We call that a mistake or an oversight, not "engineering debt" In software we'd have called it "technical debt", as if spending $600m to build a system that doesn't work and needs to be fixed at tremendous cost while wiping out all of the profits was somehow part of our bus…

Not all technical debt is bad engineering - some is great engineering that you do, knowing it won't scale or be fit for purpose forever (but it's right to do at the time, because it meets another goal - for instance speed to market, flexibility, stability, cheaper).

Software is very different to building the millennium tower - that's designed once, and when built won't be expected to substantially change or grow (at least from a structural perspective, you will change the interior). Building a skyscraper can take 5 years to complete, and when it's built it looks like the design from 5 years ago (with all the same load assumptions). With software the design is expected to change throughout the lifecycle, and should adapt to customer demand and scaling requirements, and you can't wait 5 years for perfect when 'good enough' will do and get you live.

Re: Technical debt is not debt; it’s not even technical

#38

Post by majkinetor »

TLDR

> Cunningham: I’m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem, even if that understanding is partial.

Technical debt is not about technology, but about better understanding of functional domain, after which you should refactor your current implementation to better reflect reality in the sense that there is a more clean abstraction and accompanied code.

Re: Technical debt is not debt; it’s not even technical

#40

Post by wiz21c »

jpswade wrote: post #18

Technical debt implies that it is a technical decision, when mostly it’s a business one. Debt has a negative connotation, where as it’s more like a mortgage. I always wonder if there’s an equivalent term in manufacturing.

IOW, for me technical debt is "the debt" as seen from the engineering team. While the cost of the debt is something the management takes care off (and so decide to clear it, buy it, or whatever).
Post reply on HN