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

111–120 of 178 posts

Re: All code is technical debt

#111

Post by ska »

mmcnl wrote: post #87
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…

> So yes, the core idea of technical debt resonates with developers, but not with business stakeholders.

I think that if this is the case, you are presenting it wrong. Business types are very familiar with the tradeoffs of debt financing, you have present it as being paid in effort vs. $ (which after all, have a close relationship) and they will immediately understand that a large technical debt means you can get less desired stuff done for the same input of effort. And then you collectively decide.

Agree you have to be careful about what you present as technical debt. If you need buy in from the business side, you don't want them thinking "that's just what they say when they want more time, it doesn't mean anything". It has to be pretty concrete.

Re: All code is technical debt

#114

Post by wanderr »

This article seems to be more making the case that features are technical debt, sort of. And that's a valid point too. But it is so so easy for useless code to accumulate. At every company where I've worked as an engineer, I've ended up deleting lots and lots of code, far more than I ever write. Like, half of the codebase. Largely by applying static analysis to find code that clearly never worked, the confirming that it's not used (which is usually obvious or we'd be seeing crashes). Often times it's sad to see how long that code was maintained, with engineers wasting effort on migrating it as things changed, without ever questioning whether it's even needed.

Re: All code is technical debt

#115

Post by jimmaswell »

avereveard wrote: post #104
matheusmoreira wrote: post #99

Earlier quoted context omitted.

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

That's certainly not how most people understand the term.

Re: All code is technical debt

#116

Post by rglover »

My standard for tech debt:

- Unnecessary (too many or too heavy) dependencies that can be replaced by DIY code, or at least, smaller dependencies.

- Implementations that stray from the standard set by the rest of the code in the project or actual guidelines written by a project leader (e.g., we don't use jsdoc anywhere but a developer randomly crams it in during a copypasta).

- Over-complicated implementations that serve as an ego-pleasing flex for the author, but are impossible for even an experienced developer to reason through.

- Implementations that were done to service a single customer in pursuit of short-term revenue, or, that were rushed through due to manager/stakeholder panic and inevitably collide with one of the above.

---

Keep those three in check and you'll have limited issues.

Edit: a good talk by Oliver Reichenstein (of iA Writer fame) that helped me years ago https://vimeo.com/102343006 -- it's from a design perspective but has parallels to development. One quote of his that constantly pings in my head: "slow the fuck down."

Re: All code is technical debt

#117

Post by [deleted] »

rglover wrote: post #116

My standard for tech debt: - Unnecessary (too many or too heavy) dependencies that can be replaced by DIY code, or at least, smaller dependencies. - Implementations that stray from the standard set by the rest of the code in the project or actual guidelines written by a project leader (e.g., we don't use jsdoc anywhere but a developer randomly crams it in during a copypasta). - Over-complicated implementations that s…

[deleted]

Re: All code is technical debt

#118

Post by nirvdrum »

wavemode wrote: post #89
nirvdrum wrote: post #67

Earlier quoted context omitted.

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.

Thanks for asking. I ended up revisiting the text to make sure my impression was accurate. It is more ambiguous than I recalled.

Re: All code is technical debt

#119

Post by jongjong »

Code which solves a well defined problem with the absolute minimal amount of logic necessary is not technical debt.

If a module is fully replaced later, it doesn't mean it was technical debt. Technical debt is characterized by its need to be refactored/modified in a way which is not backwards compatible. If a module can be substituted in its entirety with minimal changes which directly reflect requirement changes, then it wasn't technical debt.

Good code is about setting up components in a hierarchy which allows you to adapt to requirement changes by substituting modules as opposed to refactoring those modules.

Note that if you're adding features to an existing module, this does not count as a refactoring. Not if the module is backwards compatible with respect to its dependents. But of course when adding new features you want to stick to the minimalist philosophy so you need each module to have clear responsibilities.

Re: All code is technical debt

#120

Post by matheusmoreira »

avereveard wrote: post #104
matheusmoreira wrote: post #99

Earlier quoted context omitted.

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

I definitely agree with him about code reflecting one's understanding of the problem and its solution. I don't agree with the poor programming thing though. No one writes bad code on purpose. Sometimes things like that just slip through while I'm focusing on other issues. I do make an effort to polish things up before committing but at some point I have to decide that the code is good enough to push otherwise I'll succumb to perfectionist tendencies. I'm also a solo developer so I don't have anyone to review my code either.
Post reply on HN