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

31–40 of 178 posts

Re: All code is technical debt

#31

Post by zoogeny »

ska wrote: post #21
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…

I agree with this history, but don't think the meaning was acquired independently so much as naturally grew. Ward presents it in a sort of "optimal development" context, where what we did last year was the right thing last year, but we know more now/things have changed and we know what the right thing would be today. This is definitely happens, but doesn't allow for a lot of other real-world reasons for this mismatch…

> there is an impedance mismatch between what you want to do to/with the system today, and what the system actual is today

This is a better conceptualization compared to the idea that tech-debt is the result of shortcuts or rushed code. Tech debt arises for a lot of reasons, including shortcuts but not exclusively because of shortcuts. I've seen tech debt arise because well-meaning engineers were trying to do things "the right way".

I think it is just a kind of entropy thing that we have to fight against. A lot of confounding factors lead to code that is hard to maintain and extend. I think it is an unfair characterization to suggest it is solely because of laziness or negligence.

Re: All code is technical debt

#32

Post by anonporridge »

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 an unmaintainable mess that gradually degrades and falls to Entropy. They eventually have to hire someone to rip it all out and revert to a dumb house.

By going all in on home automation, I'm creating debt for future me and my partner to maintain it all. At the moment, I'm not convinced that this act of creation will actually create enough value to justified the debt incurred.

Re: All code is technical debt

#33

Post by abakker »

Put more directly: all choices are costs. Specifically, a choice is choosing to incur opportunity cost in order to realize some outcome.

E.g. Buying a sandwich so you can eat it to be full is choosing not to spend that $10 on anything else.

In durable and intellectual domains, choices can incur opportunity costs, but also lead to switching costs in the future. I've always understood technical debt to be the combination of opportunity costs and switching costs resultant from a specific choice that resulted in a durable physical or intellectual good.

In this way, technical debt is not a particularly complicated topic. The issue is that switching costs can be very high, and to eliminate the accumulated opportunity cost and switching costs of a previous decision, it is necessary to incur a new set of costs going forward.

There is no "debt", there is only cost. The idea that you can "owe" on a series of choices implies that you can "pay it back". This is false. You can make choices - some may be more costly than others both immediately and in the future - but all choices have costs always. To quote Rush, "if you choose not to decide, you still have made a choice".

Re: All code is technical debt

#35

Post by nirvdrum »

0xdeadbeefbabe wrote: post #15
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…

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 way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written."

The book then goes on to describe the methodology and runs through common refactorings step-by-step. Nowadays the term is used almost generically for code improvement. I'll see commit messages like "refactored the API", which violates the edict to not alter external behavior.

Languages evolve and so on, but it's remarkable to me how quickly precisely defined terms (or even new words) change their meaning in tech. My cynical take is it's easier to get management to buy into "assuming technical debt" and addressing it with a "refactor" later than it is to "cut corners" and "rewrite" the code later. As long as everyone understands the new definition I guess there isn't even anything wrong with it, but it's a shame we've then lost a term for the original meaning.

Re: All code is technical debt

#38

Post by ravenstine »

pphysch wrote: post #27
ravenstine wrote: post #13

Earlier quoted context omitted.

That's the thing. Not making the problem worse is fine and all, but most projects simply aren't removing enough. It's amazing that today's software functions as well as it does, and programmers today are lucky they can hitch a free ride on decent hardware.

Yeah. Refactors and rewrites (i.e. removing lots of code) are risky, but so is having critical CVEs and data loss events every year because of your insanely over-complicated architecture that has never been rethought in the past decade+. It's a cultural issue where we think major faults "just happen" and are not directly tied to prior product decisions, and therefore there isn't much accountability. But if you propos…

Modern software is so buggy, but it's considered the norm. I was talking to a non-technical person recently about that, and although they were at first puzzled by my view that most software is problematic, they realized that they experience the same bugs I complain about all the time. It's become so normal that people hardly notice it, but that doesn't make it better because bad software wastes human life time whether they realize it or not.

> But if you propose a major refactor, there is no question about (rightly) where the blame lies.

LOL Yep.

Worse is when the blame lies on the semi-technical cofounder of your company who, granted, achieved quite a lot on their own, wrote a barely maintainable mess. Do you really want to be the one to indirectly point out that his code needs to be replaced? Haha I think a lot of developers would rather wait for the Dilbert Principle to kick in so that the cofounder gets out of the way enough for significant changes to finally be made.

Re: All code is technical debt

#39

Post by open-paren »

I prefer to say that "code is a liability, not an asset." Liabilities are useful and help achieve goals (want a house, get a mortgage), but the code is not the goal. Code is a mechanism that achieves that goal, but more code becomes a drag.

Re: All code is technical debt

#40

Post by ska »

zoogeny wrote: post #31
ska wrote: post #21

Earlier quoted context omitted.

I agree with this history, but don't think the meaning was acquired independently so much as naturally grew. Ward presents it in a sort of "optimal development" context, where what we did last year was the right thing last year, but we know more now/things have changed and we know what the right thing would be today. This is definitely happens, but doesn't allow for a lot of other real-world reasons for this mismatch…

> there is an impedance mismatch between what you want to do to/with the system today, and what the system actual is today This is a better conceptualization compared to the idea that tech-debt is the result of shortcuts or rushed code. Tech debt arises for a lot of reasons, including shortcuts but not exclusively because of shortcuts. I've seen tech debt arise because well-meaning engineers were trying to do things…

I've used the entropy analogy also. In particular, entropy always wins in the end. But I do think it weakens the "debt" analogy to consider it the same thing, because I like the idea that this is sometimes transactional - a choice you make for benefit now which has amortized cost. I think this is a valuable idea that is separable from the problems of complexity growth, entropy, etc.

I certainly don't agree with the idea that all technical debt is due to shoddy work, that's obviously silly. I suspect that people fall into it because it is easy to understand. The original framing is more nuanced and harder to think about but no less in effect.

Post reply on HN