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

81–90 of 178 posts

Re: All code is technical debt

#81

Post by j45 »

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…

Well said.

Too often code is a proxy for complexity being added unnecessarily, consciously or unconsciously.

Premature optimization or over-engineering or burning your innovation points on shiny object syndrome can create technical debt in a different way than just taking shortcuts.

Re: All code is technical debt

#83

Post by pyromaker »

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, implement that HR system) - which would solve the particular issues for the business at that particular point in time, but may not the needs of the business later on.

For software, the issue is that we believe we can introduce technical debts, that is, it is permissible to introduce and talk about technical debts. We wouldn't necessarily talk about implementing a new HR system often.

We think writing a line of code is fast (and define what "fast" means) but it isn't.

Re: All code is technical debt

#85

Post by turtlebits »

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…

IME being in the operations space for along time, developers often oversimplify/ignore non-coding tasks, that is where I find most tech debt comes from, as the time/resources is not estimated/allocated ahead of time.

Corner cutting == tech debt

Ask any ops person and none of them will tell you they're content with the state of their infrastructure.

Re: All code is technical debt

#86

Post by NoPicklez »

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 and I can't stand it when people dilute terms to the point they become meaningless. I see it in other areas as well.

It isn't a profound thought to take a term like "technical debt" and just say well that's just everything.

Technical debt is absolutely that, adding something that incurs a level of interest, until you take the time to pay it off. In life, we often always have a level of interest to be paid.

It's a good analogy

Re: All code is technical debt

#87

Post by mmcnl »

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…

What I don't like about "technical debt" is that it's usually interpreted as "technical" debt: it's only a problem for the developers, the techies. You immediately lose the business stakeholders once you start talking about technical debt. But the problem of technical debt if a problem for everyone, not just the devs, because it is reflected in quality and time-to-market. I feel having that conversation about time-to-market and quality with business stakeholders is incredibly important and is often skipped. This in turn alienates business stakeholders from the developers, which is counter-productive.

So yes, the core idea of technical debt resonates with developers, but not with business stakeholders. So if you really think the business is going to be okay with "we're gonna slow down our time-to-market and say no to all your requests for a while because we need to pay back our technical debt" (which is something I see happening over and over again), you're just keeping them out of the loop and taking over their responsibilities without actually having their accountability. Developers shouldn't decide whether time and money should be invested in time-to-market and quality or feature delivery, but that's effectively what's happening when business is not involved in the tech debt discussion. This only leads to friction and suboptimal results.

That's why I think we really need to be careful when using the words "technical debt" and not just label everything we don't really understand or think can be improved as "technical debt". Challenge yourself: what really is the problem with this piece of code, other than that we don't like it?

Re: All code is technical debt

#88

Post by ljm »

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 perfectly anticipate the future. In that sense, it's not so much debt as it is a maintenance overhead.

Re: All code is technical debt

#89

Post by wavemode »

nirvdrum wrote: post #67
wavemode wrote: post #45

Earlier quoted context omitted.

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

Makes sense! I appreciate the clarification.

Re: All code is technical debt

#90

Post by mmcnl »

jrockway wrote: post #46

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. Som…

Code is an asset. Assets need to be managed, maintained, or else they will degrade. Assets have costs.
Post reply on HN