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

Garbage collect your technical debt (2021)

ieeexplore.ieee.org

Post reply on HN
Print view View original

11–20 of 92 posts

Re: Garbage collect your technical debt (2021)

#11

Post by dec0dedab0de »

caseyohara wrote: post #10

> Building software iteratively leads inevitably to tech debt because we choose to deliver systems before we have looked at all the requirements. Not knowing what’s next distorts our designs, and that distortion is the tech debt. This article frames technical debt as something that happens passively because you can't know future requirements. That's sometimes true, of course, but in my experience the majority of tech…

The problem is that there is never an objective right way. There are infinite wrong ways, and usually a handful of ways that are just fine with different pros and cons that are not always clear up front.

A lot of the time when people say technical debt they mean a developer not taking the time to understand some code they inherited (or they wrote and forgot about), and wanting to throw the baby out with the bathwater.

If think you ask ten developers the best way to refactor a complex program you'll get 100 answers.

But I do agree that deliberate technical debt is more common on a decent team. I definitely have left many comments like "I know it would be better if I did XYZ, or ABC, but the boss wants it now, and I'm tired, so it's going to be a monstrosity"

Re: Garbage collect your technical debt (2021)

#13

Post by nxicvyvy »

WalterSear wrote: post #9
clcaev wrote: post #6

It's not always easy to find the right words to describe why a feature pause to refactor is needed. This quote was a succinct statement that avoids analogy: "Postponing a small cleanup can transform it into a big cleanup because, over time, code builds up around the problem, and it too must be refactored."

"I'm sorry, I didn't understand much of that. Are you saying you can commit to finishing the feature on a shorter timeframe than you originally asked for? Would it help if we forgo writing tests?"

Yes, but every other feature will take ten times as long as over the next three years we will lose 90% of our best developers.

Re: Garbage collect your technical debt (2021)

#14

Post by RadiozRadioz »

nxicvyvy wrote: post #13
WalterSear wrote: post #9

Earlier quoted context omitted.

"I'm sorry, I didn't understand much of that. Are you saying you can commit to finishing the feature on a shorter timeframe than you originally asked for? Would it help if we forgo writing tests?"

Yes, but every other feature will take ten times as long as over the next three years we will lose 90% of our best developers.

"This is the last feature we will tell you to rush, we promise. We really need just this one, and then we're good."

Re: Garbage collect your technical debt (2021)

#15

Post by fmbb »

caseyohara wrote: post #10

> Building software iteratively leads inevitably to tech debt because we choose to deliver systems before we have looked at all the requirements. Not knowing what’s next distorts our designs, and that distortion is the tech debt. This article frames technical debt as something that happens passively because you can't know future requirements. That's sometimes true, of course, but in my experience the majority of tech…

There is often a third alternative: do not shoehorn it into something, nor rebuild what you have to fit this new thing, instead build the new thing on the side.

I sometimes have worked with engineers who believe they know what “the right way” is, or spend a lot of time trying to figure it out. And I have certainly worked on legacy systems persons like that have built. It’s not all fun and games.

The less we entangle things the easier it is to remove cruft when it is no longer needed.

Re: Garbage collect your technical debt (2021)

#16

Post by TheDudeMan »

WalterSear wrote: post #9
clcaev wrote: post #6

It's not always easy to find the right words to describe why a feature pause to refactor is needed. This quote was a succinct statement that avoids analogy: "Postponing a small cleanup can transform it into a big cleanup because, over time, code builds up around the problem, and it too must be refactored."

"I'm sorry, I didn't understand much of that. Are you saying you can commit to finishing the feature on a shorter timeframe than you originally asked for? Would it help if we forgo writing tests?"

Triggered

Re: Garbage collect your technical debt (2021)

#17

Post by [deleted] »

RadiozRadioz wrote: post #14
nxicvyvy wrote: post #13

Earlier quoted context omitted.

Yes, but every other feature will take ten times as long as over the next three years we will lose 90% of our best developers.

"This is the last feature we will tell you to rush, we promise. We really need just this one, and then we're good."

[deleted]

Re: Garbage collect your technical debt (2021)

#19

Post by bitwize »

RAII your technical debt: make a note of every time you slap something together the expedient way, and schedule a future time to refactor after the legitimacy of expediency goes "out of scope", e.g., after a major product demo.

One could even add a CI/CD task to remind the user of when refactorings are due (and refuse to successfully build until they are addressed). Since debt is created by borrowing, one could call this the "borrow checker".

Re: Garbage collect your technical debt (2021)

#20

Post by 0xDEAFBEAD »

clcaev wrote: post #6

It's not always easy to find the right words to describe why a feature pause to refactor is needed. This quote was a succinct statement that avoids analogy: "Postponing a small cleanup can transform it into a big cleanup because, over time, code builds up around the problem, and it too must be refactored."

This suggests a "just in time" approach to cleaning up tech debt. Clean it up just before you write code which would otherwise depend on the debt.
Post reply on HN