Live data from Hacker News

Garbage collect your technical debt (2021)

ieeexplore.ieee.org

1–10 of 92 posts

Re: Garbage collect your technical debt (2021)

#3
A quirk of IEEE's publishing system is that it drops the abstract, instead using the first paragraph. Here is the abstract [1]:

The iterative process that a team follows is a bit like a garbage collection algorithm, and we can compare software development processes like we can any algorithm. A process can help developers do two things: clean up tech debt after it exists, or avoid creating it. When an iterative process does neither, tech debt buildup will lead to bankruptcy, so it is only suitable for projects with a short lifespan. A process that does both has the best chance at minimizing tech debt over a long lifespan. In particular, focusing on the system’s design will keep tech debt low.

[1] https://www.georgefairbanks.com/ieee-software-v38-n5-sep-202...

Re: Garbage collect your technical debt (2021)

#4

A quirk of IEEE's publishing system is that it drops the abstract, instead using the first paragraph. Here is the abstract [1]: The iterative process that a team follows is a bit like a garbage collection algorithm, and we can compare software development processes like we can any algorithm. A process can help developers do two things: clean up tech debt after it exists, or avoid creating it. When an iterative proces…

[deleted]

Re: Garbage collect your technical debt (2021)

#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."

Re: Garbage collect your technical debt (2021)

#7
> pushed a routine re-acceptance of those terms

Oh, of course, of course. Why, this is so mundane, why would anyone even bother to read it?

> For content processed or stored on Adobe servers, Adobe may use technologies and other processes, including escalation for manual (human) review, to screen for certain types of illegal content (such as child sexual abuse material), or other abusive content or behavior (for example, patterns of activity that indicate spam or phishing).

They are going to use AI to scan through all content...for your protection. Does Adobe have a problem with people using their cloud to produce child abuse material? I think we all recognize Bitcoin is used for illegal activity. But I never considered Adobe being associated with CP. I guess that's what they're going with...

I feel like this is a trope at this point. Just like Microsoft Recall, no one believes or trusts this won't eventually turn into them using your IP for themselves via AI, and then eventually by the government. That's the bottom line.

To really put a point on it, they are saying they're swipping a spider off us while they slip their hands down our pants.

Re: Garbage collect your technical debt (2021)

#8

> pushed a routine re-acceptance of those terms Oh, of course, of course. Why, this is so mundane, why would anyone even bother to read it? > For content processed or stored on Adobe servers, Adobe may use technologies and other processes, including escalation for manual (human) review, to screen for certain types of illegal content (such as child sexual abuse material), or other abusive content or behavior (for exam…

commented on the wrong post?

Re: Garbage collect your technical debt (2021)

#9
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?"

Re: Garbage collect your technical debt (2021)

#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 technical debt is accrued deliberately in a much more active process.

When developing a new feature that doesn't neatly fit into the existing system, you must choose between two compromises:

1. Build it the "fast way", shoehorning the feature into the system just enough to work, compromising quality for velocity and accruing technical debt; or

2. Build it the "right way", adapting the system to accommodate the new feature, compromising velocity for quality to avoid technical debt.

This is usually a deliberate decision, so choosing to accrue technical debt is an active process. The only way it could be passive like the article describes is if the developers don't know or otherwise don't consider the "right way" and go straight for the "fast way". I hope to never work on a team that operates like that.

Post reply on HN