Technical debt is not debt; it’s not even technical • Hacker News Board

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

#51

Post by xondono » Fri, Jul 30, 2021, 8:47 AM UTC

The argument is a little nonsensical.

1. Is "technical debt" debt: If it walks like a duck...

Not all debt is in the form of retail loans. Leaving a "IOU" note where someones lunch was, is a form of debt (a very dangerous one). Good luck trying to find out your interest rate in advance.

2. Is "technical debt" technical: If we follow the author's logic, I guess now financial debt is not financial. Financial debt will also affect:

   - Competitiveness by slowing/speeding up new product development.

   - Costs (short-term decrease/long-term increases in development cycles)

   - Customer satisfaction

   - Whether a company can survive

That's the point altogether, "technical debt" behaves in similar ways to financial debt.

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

#52

Post by dub » Fri, Jul 30, 2021, 8:53 AM UTC

xondono wrote: post #48

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…

I disagree. Building complex solutions that you don't really need is also "bad engineering". Part of the complexity comes from the fact that the needs that software projects solve are not fixed, they change during the products life cycle. Even architects use technical debt, it just comes in different ways. Instead of trying to plan what every room is for, architects leave empty sections, to be determined later. A lot…

Seems like you feel that establishing data access patterns that have the possibility of scaling up to 100x more users requires an additional 3 weeks of initial developer time

I'm not sure I agree that an engineer experienced in building scalable systems will need 3 extra weeks to pick a schema and data access pattern that's scalable.

You don't have to actually _use_ spanner or cockroach or vitess in your initial prototype if you don't want to, but it seems entirely reasonable to have an _idea_ of what the story would look like to migrate to a horizontally-scalable approach if product gains traction so it doesn't end up being a multi-year project later.

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

#53

Post by bertylicious » Fri, Jul 30, 2021, 8:53 AM UTC

pdimitar wrote: post #43

> Take a minute and write an answer to the question, “What is technical debt?” Then read this article and reread your answer — and see if it still makes sense. This really is NOT how you start an article. You only come across as needlessly assertive and arrogant. > Nobody explained technical debt; we assumed it was a fundamental property of the work. Total BS. Literally every manager I ever addressed in a sentence wh…

The time it took you to write this rant would have been enough to finish reading the article...

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

#54

Post by pdimitar » Fri, Jul 30, 2021, 8:56 AM UTC

bertylicious wrote: post #53

pdimitar wrote: post #43

> Take a minute and write an answer to the question, “What is technical debt?” Then read this article and reread your answer — and see if it still makes sense. This really is NOT how you start an article. You only come across as needlessly assertive and arrogant. > Nobody explained technical debt; we assumed it was a fundamental property of the work. Total BS. Literally every manager I ever addressed in a sentence wh…

The time it took you to write this rant would have been enough to finish reading the article...

I already clearly stated why I don't want to. Maybe you should have read my comment fully. ;)

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

#55

Post by morgelgluff » Fri, Jul 30, 2021, 9:21 AM UTC

My pet issue with technical debt, is what happens when engineers are allowed to pay it down.

In the best case people embark on well-informed yet insane ”version 2.0” over-engineering binges. This can be nice, but is often a waste of time.

Quite often the ones who cried “muh technical debt” in every meeting simply did not understand the problem being solved by the debty code, and end up making something novel but equally problematic.

In the worst case, you have a combination of ignorance and best-practice-hysteria that gets applied to actually-fit-for-purpose code. Then the 200 lines of performant and correct code that takes two hours to fully understand, gets turned into 2000 lines of deeply nested class hierarchies mixed with immutable FP-wank that takes several days to get a grasp of and both fails to handle real-world data (“not in the specification!”) and tanks system performance (“premature optimizations!”).

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

#56

Post by afarrell » Fri, Jul 30, 2021, 9:26 AM UTC

pdimitar wrote: post #47

afarrell wrote: post #21

Earlier quoted context omitted.

> This is somewhat of a semantics argument It is important to occasionally have arguments to clarify semantics so we maintain the meaningfulness of our language. Otherwise, we lose the ability to communicate. Some people believe that meaningful communication is unimportant. Those people are wrong.

We should periodically make sure we use common terms, yes, but I find the author's tone hugely inappropriate. He seems a bit rebellious against the notion of "technical debt to the masses means something else than it means to me". Statistically and historically speaking, he's waging a losing battle and I find myself not interested about what he believes technical debt is. Furthermore, what academia thinks of technica…

> what academia thinks of technical debt is seriously irrelevant. Academics don't write code for a living. Their take on this matter isn't super important.

I initially agree strongly, but then I remember that labs maintain FORTRAN codebases for years. So I'm curious about their view of technical debt, but its definitely in a different context.

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

#57

Post by AstralStorm » Fri, Jul 30, 2021, 9:28 AM UTC

morgelgluff wrote: post #55

My pet issue with technical debt, is what happens when engineers are allowed to pay it down. In the best case people embark on well-informed yet insane ”version 2.0” over-engineering binges. This can be nice, but is often a waste of time. Quite often the ones who cried “muh technical debt” in every meeting simply did not understand the problem being solved by the debty code, and end up making something novel but equa…

That's what you get from inexperience not from paying off the debt.

It's called second system effect and it's relatively easy to avoid by methodically documenting original and mercilessly avoiding adding features.

And this includes design features that are not immediately shown to save a lot of time and code. Every such feature needs an advocate and also a prosecutor, and alternatives have to be briefly explored using a prototype.

The worst mess is actually trying to pay off the "debt" in installments by taking on new one. Then running out of time or shifting focus, ending up with double the problem and half the readability.

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

#58

Post by pdimitar » Fri, Jul 30, 2021, 9:41 AM UTC

afarrell wrote: post #56

pdimitar wrote: post #47

Earlier quoted context omitted.

We should periodically make sure we use common terms, yes, but I find the author's tone hugely inappropriate. He seems a bit rebellious against the notion of "technical debt to the masses means something else than it means to me". Statistically and historically speaking, he's waging a losing battle and I find myself not interested about what he believes technical debt is. Furthermore, what academia thinks of technica…

> what academia thinks of technical debt is seriously irrelevant. Academics don't write code for a living. Their take on this matter isn't super important. I initially agree strongly, but then I remember that labs maintain FORTRAN codebases for years. So I'm curious about their view of technical debt, but its definitely in a different context.

I agree that there used to be an overlap between an academic and a programmer. But as you pointed out, it hasn't been the case for a long time.

Plus, I'm not really sure good practices mattered to them even back then. Academics, whether they're programmers or not, chase different goals and have other incentives.

Like you, I'd love listening to one of them one day (if anyone speaks up). I'm sure there will be a few pearls of wisdom in such a shared experience.

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

#59

Post by AstralStorm » Fri, Jul 30, 2021, 9:43 AM UTC

ggm wrote: post #31

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 g…

And you can get the debt vindicated too, by being unable to further develop or deploy the software due to changing environment or requirements, especially in a timely manner.

Tends to happen at the worst of times when you're least prepared.

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

#60

Post by AstralStorm » Fri, Jul 30, 2021, 9:46 AM UTC

majkinetor wrote: post #38

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 an…

That's just one part of it. In modern development practices you have dependencies, each being at risk of getting outdated or insecure. Even if it's the programming language, build environment or OS.

No abstraction will save you from this.