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

61–70 of 178 posts

Re: All code is technical debt

#61

Post by tshaddox »

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…

From what I can tell, the definition in the link you provided is precisely what you're saying it's not. He says this:

> The explanation I gave to my boss, and this was financial software, was a financial analogy I called "the debt metaphor". And that said that if we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were gonna continually stumble over that disagreement and that would slow us down which was like paying interest on a loan.

So indeed, his definition of technical debt is explicitly that by rushing software development now you will slow down future development.

The specific software engineering task that caused him to develop the analogy was about rewriting some code to incorporate new learnings, but the analogy itself is clearly applicable to any software engineering task that could be deferred to the future (with a cost).

Re: All code is technical debt

#62

Post by seadan83 »

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 don't think the analogy breaks down per-say. Adding features is akin to adding a percentage interest rate. Some add more than others, but the cost of adding a feature is sometimes (often) dependent upon the existing features in the system.

Coding & story-writing is a good analogy. If you are inserting a new scene into a large anthology, you need to make sure the new scene fits with everything else. OTOH, writing a brand new story does not have this constraint / cost.

Which is all to say, software is an asset, code is a cost. The functionality of software is the valuable thing, all the code to do that is overhead. Thus, every line of code has a cost, and an ongoing cost that is forever then payed (which is exactly the interest; simply taking the time to scan/read over a line, to scan between 5 files vs 20, those are all ongoing costs)

Re: All code is technical debt

#63

Post by veucast »

It's interesting to see someone putting a positive spin to technical debt. The level of technical debt you can afford taking on (technical risk) is heavily dependent on how you define technical debt at your company. You must understand how taking on a technical risk will have an impact in the current and future operation of the entire business/product/team. Not all technical debts are created equal, so to encourage people to see it as a positive thing or risk worth taking, without giving them this disclaimer is irresponsible.

Re: All code is technical debt

#64

Post by [deleted] »

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…

[deleted]

Re: All code is technical debt

#65

Post by juped »

tomxor wrote: post #51
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…

> 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 [...] Oh I suspect Ward's context was even more idealistic. That there was a problem to be solved, and there were few to no moving targets, the only differences over time were in the programmer's heads as they…

I think this is right; the chaos of shifting or contradictory requirements can leave scars on the physical codebase reflecting this history, and so can attaining a better understanding of the problem from working on it, if one isn't careful to refactor (original sense) rather than adding new hacks on top. But the prescription for addressing each situation is pretty different.

Re: All code is technical debt

#67

Post by nirvdrum »

wavemode wrote: post #45
nirvdrum wrote: post #35

Earlier quoted context omitted.

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…

Perhaps my initial selection was too short. I was trying to avoid copying out whole sections of the book. Overall, I think the book is less ambiguous than the one definition I presented shows. The entirety of the text reinforces different aspects of that definition.

Fowler goes on to elaborate on the definition in chapter two, where he presents two context-dependent definitions (one a noun, the other a verb). The noun form is a specific type of change and the verb is the application of one or more of the nouns. E.g., "Move Method" and "Move Field" are types of refactorings. These are defined as changes made "without changing its observable behavior." To further qualify, he states "[o]nly changes to make the software easier to understand are refactorings." By way of example, he compares to performance optimization where he says: "A good contrast is performance optimization. Like refactoring, performance optimization does not usually change the behavior of a component (other than its speed); it only alters the internal structure."

Maybe it's just the domain or languages I work with. Nowadays I never see anyone apply refactorings as described in the book. I'm sure devs implicitly apply several of them, perhaps without the rigor presented, and that's understandable. But, I often see "refactoring" just as a catch-all for any code change.

While certainly there are some blurred lines in terms of what constitutes a refactoring or not, I think Fowler handles the product/API split fairly well. He adds:

"The second thing I want to highlight is that refactoring does not change the observable behavior of the software. The software still carries out the same function that it did before. Any user, whether an end user or another programmer, cannot tell things have changed."

By stating a programmer should not be able to tell things have changed, I think we can at least anchor public APIs as something that should not be adjusted in a refactoring. Such a change could improve the maintenance of the software or the quality of the product, but I don't think it fits the narrow definition of a refactoring. Admittedly, the part about the observable behavior of the software not changing can get murky. But, I think Fowler tries to scope this more at the code level than at the product level.

Re: All code is technical debt

#68

Post by crazygringo »

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…

Completely agreed.

The idea that "all code is technical debt" because all requirements could hypothetically change someday, makes as much sense as saying "all currencies have no value" because 1,000 years from now we might not be using any of them.

Technical debt is not defined in terms of possible future requirements, it is defined in terms of current requirements. Code that elegantly and concisely expresses current requirements is debt-free. Code that is a mix of elegantly expressing old requirements, with new requirements expressed in a hacky fast way, has debt.

But trying to judge code in reference to all possible future requirements is utterly nonsensical. You can't measure that. It's literally meaningless.

So no, all code is not technical debt. Technical debt is technical debt, and clean code is clean code. Trying to redefine words to mean their opposite helps no one. That way lies madness.

Re: All code is technical debt

#69

Post by chuckadams »

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…

My brother coined a term that I really love: "feature karma". He's an actual Buddhist, so he used the term "karma" not to mean a simple score with only positive connotations, but as something you're chained to and must work off should you at some point want to move past it.

Re: All code is technical debt

#70

Post by Phiwise_ »

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…

Absolutely agreed. Articles in this vein rather get my goat, especially because the analogy to real debt is more clear: If someone wrote a consumer finance article like "All purchases of things other than cans of beans and Certificates of Deposit are like Mortgages, because what if your industry collapses tomorrow?" most people have the good sense to complain that the usually decent advice of saving a bit for a rainy day was being way exaggerated. And yet pieces that run something like "All programming of things other than washing machine microcontrollers are like technical debt, because what if your customer's needs suddenly change entirely?" get much more play. Sure, disasters can happen, and it pays to reserve some resources to be ready for them, but it also pays to use resources when times are good to expand. It seems to me Cunningham's point was to encourage a move towards balance; headlines that don't overshoot the mark.
Post reply on HN