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

All code is technical debt

tokyodev.com

Post reply on HN
Print view View original

41–50 of 178 posts

Re: All code is technical debt

#41

Post by jahewson »

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…

In hindsight Ward’s choice of the word “debt” may not have been the right one. It feels more like “legacy code”, in that there was nothing wrong with it at the time. Its impact on newer parts of the system is to create a “legacy burden”.

Of course if there was something wrong with the code at the time then it’s more of a “proficiency debt” (or burden) where the shortcut taken was not in the coding but in not reading the docs and practicing the craft.

Re: All code is technical debt

#42

Post by indymike »

"I prefer my products to have less code in them." -- Can't remember what smarter person than I said it...

Conceptually, I think every developer eventually realizes that every line of code ends up adding maintenance cost, and potentially constraints on the future. "Technical Debt" is one way to think about it - if you don't have the resources to maintain. Otherwise, it's just a cost as others have pointed out.

Maintenance is harder than most people think: documentation, translations, tests, all are part of this cost.

Re: All code is technical debt

#43

Post by flerchin »

anonporridge wrote: post #32
anonporridge wrote: post #17

All wealth (negentropy/complexity) creation creates debt. Whenever we build, we use intelligence to rearrange things in more complex ways that don't naturally occur. Ideally, this creates value by unlocking things we want that we previously couldn't have. But this work always creates a burden on the future (debt) to maintain the complexity we built. This is especially true if the complexity doesn't gracefully degrade…

Addendum; A concrete example of this conflict that I've been wrestling with recently. I've been considering going all in on home automation. Zigbee devices and sensors everywhere managed with custom rules on Home Assistant. I want to get to the point where I don't ever have to touch a light switch. However, I also recognize stories of others who have done this, and then died leaving their less technical spouse with a…

This is exactly why I haven't automated my newest house. All the automation in my last one was net-negative to the buyer.

Re: All code is technical debt

#45

Post by wavemode »

nirvdrum wrote: post #35
0xdeadbeefbabe wrote: post #15

Earlier quoted context omitted.

I had no idea Cunningham was so thoughtful about it. It's a term used by less thoughtful people in most of my experience.

I think something similar happened with the term "refactoring." While it had been in use by a small community beforehand, Fowler's "Refactoring" book is what really opened it up to a wider audience. The book defines refactoring as: "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined wa…

> Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.

That's the meaning of refactoring that I typically hear, tbh.

I guess it just depends on what one means by "external behavior". Changing a function signature changes the external behavior of that function for callers of that function, but not for other modules. Changing the interface of a module changes its external behavior for other modules depending on it, but not for clients of the whole server. Changing an API changes the external behavior for the client, but not for the end user (to whom API changes are invisible and irrelevant).

Traditionally, one might say "if the tests still pass, it was a refactor." Though nowadays that's probably not true either, as business code tends to contain a lot more internal testing than it used to (which is good! but also bad).

Re: All code is technical debt

#46

Post by jrockway »

Code is inventory, not debt. Inventory is good and bad. If someone comes to your store and everything is out of stock, you will make $0. So you want some inventory. But if you have too much inventory and nobody is buying anything, then your inventory just rusts in storage and becomes worthless. Code is pretty much exactly the same. Most features are sitting in storage in the hopes that someone comes by to buy it. Sometimes they do! Sometimes they don't. If you were the guy with a toilet paper warehouse in March 2020 you did great.

Re: All code is technical debt

#48

Post by metabagel »

mjr00 wrote: post #29

The author is conflating a few different things. All code and features are overhead . It requires maintenance when it breaks, or requirements change. It increases complexity when working on other parts of the system, as other new features have to ask "how does this interact with existing features?", even if the answer to that is "it doesn't". At Amazon one of the VPs had a rule of thumb that if a dev or team worked f…

And sometimes it can be difficult to tell when a complex solution is actually appropriate and not a candidate for being re-implemented.

Re: All code is technical debt

#50

Post by sorokod »

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…

Yes, a bit silly this. Code is means to an end, it makes sence to think of code as liability (maintenance cost, inevitable bugs, etc .. ) but this must be contrasted with the value it provides within some reasonable timeframe.
Post reply on HN