All code is technical debt • Hacker News Board

Re: All code is technical debt

#101

Post by smallnamespace » Wed, Dec 20, 2023, 10:53 PM UTC

ljm wrote: post #88

ska wrote: post #11

I think the author is basically diluting the term "technical debt" to the point it becomes meaningless. Much of what they are talking about is the inherent difficulty of managing complexity, mixed with the difficulty of understanding requirements/defining features well. I think "technical debt" as a term is overused and sometimes misapplied, but the core idea resonates with many developers, at least the way it is mos…

I think it could make more sense if it's rephrased to 'all code is a liability'. Then the equation is simpler. More code = more to maintain = more liability. It says nothing about the quality of the code, just the quantity. Tech debt is a trade-off between near term and long term ambitions - it is literally impossible to build a successful project without accruing this kind of debt, simply because you cannot perfectl…

'All code is a liability' is also not a particularly accurate application of finance jargon.

A car or a house also have ongoing maintenance costs, but they would normally be classified as assets (because they generally produce value in excess of the maintenance, or because you can sell them in a secondary market).

I think an accurate, useful, but not very catchy rephrasing is just 'working code requires ongoing maintenance'.

Re: All code is technical debt

#102

Post by lnxg33k1 » Wed, Dec 20, 2023, 10:54 PM UTC

I personally consider tech debt code that is hard to reason about, change, understand or not covered by unit test. I think the author just wanted to say something nonsense to go viral and get share/increase klout, but if the concept of code is symmetrical to the one of tech debt then the concept of tech debt is useless and we need something else to scope code that is hard to be worked on, and back to square one

Re: All code is technical debt

#103

Post by andrewprock » Wed, Dec 20, 2023, 10:57 PM UTC

ljm wrote: post #88

ska wrote: post #11

I think the author is basically diluting the term "technical debt" to the point it becomes meaningless. Much of what they are talking about is the inherent difficulty of managing complexity, mixed with the difficulty of understanding requirements/defining features well. I think "technical debt" as a term is overused and sometimes misapplied, but the core idea resonates with many developers, at least the way it is mos…

I think it could make more sense if it's rephrased to 'all code is a liability'. Then the equation is simpler. More code = more to maintain = more liability. It says nothing about the quality of the code, just the quantity. Tech debt is a trade-off between near term and long term ambitions - it is literally impossible to build a successful project without accruing this kind of debt, simply because you cannot perfectl…

And all code is an asset. Have we just reduced the conversation to: everything has a cost, and everything has a benefit?

Re: All code is technical debt

#104

Post by avereveard » Wed, Dec 20, 2023, 11:18 PM UTC

matheusmoreira wrote: post #99

ska wrote: post #11

I think the author is basically diluting the term "technical debt" to the point it becomes meaningless. Much of what they are talking about is the inherent difficulty of managing complexity, mixed with the difficulty of understanding requirements/defining features well. I think "technical debt" as a term is overused and sometimes misapplied, but the core idea resonates with many developers, at least the way it is mos…

I agree. Technical debt is a very useful concept and it's not helpful to dilute its meaning. Only a couple days ago I decided to change some data structure. It was needlessly hard because I had neglected to create an accessor function and was instead accessing it directly everywhere. Had to change every bit of code that accessed the structure's fields. That's technical debt: something the programmer should have done…

No sorry that is just bad encapsulation and goes under poor programming.Technical debt occurs when you write a good program to your current understanding of the solution knowing that the full understanding of the solution will come later, and that you need to do something now to get to that learning point later, and so you have to repay your partial understanding at the beginning with refactoring later.

Here, heed Ward words directly, poor programming is not debt, and debt doesn't cover "whatever reason programmer may have" but has a specific well defined scope: https://m.youtube.com/watch?v=pqeJFYwnkjE&t=198

Re: All code is technical debt

#105

Post by drewcoo » Wed, Dec 20, 2023, 11:43 PM UTC

tomxor wrote: post #5

> Technical debt, as originally coined by Ward Cunningham, is the idea that you can gain a temporary speed boost by rushing software development, at the cost of slowing down future development. No! Ward's blog post linked in this very paragraph [0] describes the original definition quite clearly, and it's not this. The term was originally intended to describe the delta between a programmer's current understanding acq…

> the modern definition that it has acquired independently, where by programmers knowingly take shortcuts

No error! That seems to be included in this summary, which Cunningham reviewed:

https://www.agilealliance.org/wp-content/uploads/2016/05/Int...

Quoth the PDF:

> When taking short cuts and delivering code that is not quite right for the programming task of the moment, a development team incurs Technical Debt.

Re: All code is technical debt

#106

Post by dilyevsky » Wed, Dec 20, 2023, 11:46 PM UTC

pyromaker wrote: post #83

Ultimately, everything can be debt. If code is technical debt, a HR system or a process that you implement for the company at that particular point in time is also a debt (process debt? HR debt? debt nonetheless). If we are trying to deliver fast by expediting software development and taking shortcuts (technical debt), another department can also do something similar (quick, our HR process is slow and cumbersome, imp…

Yeah “code is debt” seems to be popular meme among the “thought leaders” these days. Somehow their baroque processes (eg scrum), nonsense okrs and out of touch roadmaps are never debt - curious, right?

Re: All code is technical debt

#107

Post by drewcoo » Wed, Dec 20, 2023, 11:46 PM UTC

mjw_byrne wrote: post #100

Taking a useful concept and stretching it to an extreme in order to generate a counterintuitive-but-plausible soundbite is not the same thing as wisdom. Other examples that come to mind are "a complete rewrite is always a mistake" (no, it just has different risks/rewards), "if you are reading this part of the docs, you are trying to be too clever" (your API is too much for my puny brain is it?) and "all functions are…

> Taking a useful concept and stretching it to an extreme in order to generate a counterintuitive-but-plausible soundbite is not the same thing as wisdom.

That seems to describe most of the programming clickbait here. I could swear there used to be more discussion of startups . . .

Re: All code is technical debt

#108

Post by resters » Wed, Dec 20, 2023, 11:51 PM UTC

I've ranted about this before. Everyone would like to have infinite time to write the best possible code and do everything right. In a business, particularly a time constrained or financially constrained one, the art of running the business entails deciding which corners to cut, what tradeoffs to make.

Ironically, startups hire inexperienced people who often over-peform but sometimes underperform. A less risky approach would be to spend more (cash or equity) to hire people who are more of a sure thing. This could be called "execution debt" but it is accepted as visionary and associated with believing in people and being able to sense talent.

Tech (architecture, code, devops, etc.) is no different. A highly skilled team will be able to make the right tradeoffs and cut the right corners.

Tech debt is usually what people call something that appears in hindsight to have been the wrong corner to cut, however one would need a time machine to understand why the decision were made and what was competing for time/attention/resources and why.

Engineering is the discipline of managing tradeoffs to create something.

When working with a codebase that appears to be technical debt, the important thing to ask is what the options are today to address it. It may be beautifully written, clean code that uses the wrong abstractions, or it may be a solid architecture with some ugly code and style that needs to be addressed. Lots of people have biases due to their own preferences, but the thing to rememeber is that chances are the code was not made by someone with infinite time and perfect knowledge.

Re: All code is technical debt

#109

Post by wredue » Thu, Dec 21, 2023, 12:02 AM UTC

ska wrote: post #11

I think the author is basically diluting the term "technical debt" to the point it becomes meaningless. Much of what they are talking about is the inherent difficulty of managing complexity, mixed with the difficulty of understanding requirements/defining features well. I think "technical debt" as a term is overused and sometimes misapplied, but the core idea resonates with many developers, at least the way it is mos…

I especially likes the discussion of “adding assumptions” where it became readily apparent that there was zero experience guiding anything in their product, and when they said “assumption”, what they actually meant was “completely and utterly devoid of any semblance of planning what-so-ever”

Re: All code is technical debt

#110

Post by csbartus » Thu, Dec 21, 2023, 12:15 AM UTC

I think code / coding is overrated. Coding is debt.

If we look at math / category theory we have functorial semantics, which means semantics (code) is auto-generated from syntax (design): https://www.algebraicjulia.org/assets/slides/nist-workshop-2...

If we look in another direction we see LLMs which (will one day) generate code from design.

If I look back those years in my career, I was always paid to write the same code all over again (lists, trees, tables, menus, user profiles, shopping carts, dashboards, heroes, apis, databases...), each time in a different context (given by the company) ... Such a waste of my time, and my employers money.

Today at least in the MVP / startup scene coding is debt / obsolete. Startups all should go no-code.

Later, after the startup phase, companies should focus _only_ on provably-correct, likely-correct understanding of their problem domain, on a design specific to their audience, and rapid iteration. The rest, coding, should be not no-code, but fully automatic yet provably correct (in the sense of total and partial correctness)

I hope, and I wish coding will be eliminated. It's a big fun writing machine code in Assembly, algorithms in C/C++, full-stack web apps in Ruby on Rails, and user interfaces in React.

But after a while it's not sustainable neither emotionally nor economically.