[HN Gopher] Garbage collect your technical debt (2021)
___________________________________________________________________
Garbage collect your technical debt (2021)
Author : gfairbanks
Score : 54 points
Date : 2024-06-08 11:54 UTC (11 hours ago)
(HTM) web link (ieeexplore.ieee.org)
(TXT) w3m dump (ieeexplore.ieee.org)
| Rochus wrote:
| It even rhymes ;-)
| oriel wrote:
| Schoolhouse Rock for Coders?
| gfairbanks wrote:
| 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...
| clcaev wrote:
| 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."
| WalterSear wrote:
| "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?"
| nxicvyvy wrote:
| 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.
| RadiozRadioz wrote:
| "This is the last feature we will tell you to rush, we
| promise. We really need just this one, and then we're
| good."
| notjoemama wrote:
| > 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.
| rrdharan wrote:
| commented on the wrong post?
| caseyohara wrote:
| > 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.
| dec0dedab0de wrote:
| 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"
| fmbb wrote:
| 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.
| gumby wrote:
| Incremental collection is preferred in this case, as stop-and-
| copy collection leads to Second System Syndrome.
___________________________________________________________________
(page generated 2024-06-08 23:00 UTC)