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

41–50 of 92 posts

Re: Garbage collect your technical debt (2021)

#41

Post by 0xDEAFBEAD »

0xDEAFBEAD wrote: post #38
physicles wrote: post #31

Earlier quoted context omitted.

I recently needed to make a change in how something common is done across several services. I made the change in one place (and have some passing unit tests), but then I realized that I’d have to duplicate more code than I’d like. So I’ll take a couple days to pull all related functionality out into a shared library. This refactoring could’ve been done ages ago — there’s already some messy and duplicate code there —…

Makes sense. I guess for any given refactoring, the advantage of doing it sooner is that you get residual recurring benefits sooner. And the advantage of doing it later is you have more information about the requirements of your application and the "correct" way to do the refactor (or even if that code is going to be a long-lasting part of the app, cc Lindy effect). So whenever you touch any given piece of code which…

Also, as you alluded to, if you're changing related code which will require manual testing, then that decreases testing costs, if they're shared across the refactor and the new code.

Re: Garbage collect your technical debt (2021)

#42

Post by physicles »

0xDEAFBEAD wrote: post #38
physicles wrote: post #31

Earlier quoted context omitted.

I recently needed to make a change in how something common is done across several services. I made the change in one place (and have some passing unit tests), but then I realized that I’d have to duplicate more code than I’d like. So I’ll take a couple days to pull all related functionality out into a shared library. This refactoring could’ve been done ages ago — there’s already some messy and duplicate code there —…

Makes sense. I guess for any given refactoring, the advantage of doing it sooner is that you get residual recurring benefits sooner. And the advantage of doing it later is you have more information about the requirements of your application and the "correct" way to do the refactor (or even if that code is going to be a long-lasting part of the app, cc Lindy effect). So whenever you touch any given piece of code which…

Yeah I’ve got about five ideas for refactors that will make my life noticeably better. I’ve been pondering some of them for more than a year, slowly improving the design, but I’m still waiting for the right time when the ROI is higher.

Re: Garbage collect your technical debt (2021)

#43

Post by MaxBarraclough »

theshrike79 wrote: post #40
0xDEAFBEAD wrote: post #20

Earlier quoted context omitted.

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.

"Always leave the code you're editing a little better than you found it" - Robert C. Martin (Uncle Bob) There's no point in refactoring the whole thing. Maybe add a longer comment explaining the logic you had to decipher when you encountered the code. Rename a few variables from foo, bar and baz tom something more descriptive etc.

> There's no point in refactoring the whole thing

Deep architectural/design flaws in a codebase can't always be addressed using a series of small independent changes.

Re: Garbage collect your technical debt (2021)

#45

Post by theshrike79 »

MaxBarraclough wrote: post #43
theshrike79 wrote: post #40

Earlier quoted context omitted.

"Always leave the code you're editing a little better than you found it" - Robert C. Martin (Uncle Bob) There's no point in refactoring the whole thing. Maybe add a longer comment explaining the logic you had to decipher when you encountered the code. Rename a few variables from foo, bar and baz tom something more descriptive etc.

> There's no point in refactoring the whole thing Deep architectural/design flaws in a codebase can't always be addressed using a series of small independent changes.

Yes, but that's also not a thing you do on the side with extra hours you have left over here and there.

It's basically refactoring/rewriting the whole part of the system in most cases, which is a full project in itself.

Re: Garbage collect your technical debt (2021)

#46

Post by yarekt »

0xDEAFBEAD wrote: post #38
physicles wrote: post #31

Earlier quoted context omitted.

I recently needed to make a change in how something common is done across several services. I made the change in one place (and have some passing unit tests), but then I realized that I’d have to duplicate more code than I’d like. So I’ll take a couple days to pull all related functionality out into a shared library. This refactoring could’ve been done ages ago — there’s already some messy and duplicate code there —…

Makes sense. I guess for any given refactoring, the advantage of doing it sooner is that you get residual recurring benefits sooner. And the advantage of doing it later is you have more information about the requirements of your application and the "correct" way to do the refactor (or even if that code is going to be a long-lasting part of the app, cc Lindy effect). So whenever you touch any given piece of code which…

Interesting, I think this is part of what the article is alluding to: what happens with tech debt is more to do with the team’s process rather than with the tech debt itself. Some teams are stuck in a process that makes them unable to tackle the problems even if they want to due to that process.

Of course you could just say “change the process” but it’s also obvious that there are many other factors and pressures that are non trivial

Re: Garbage collect your technical debt (2021)

#47

Post by yarekt »

0xDEAFBEAD wrote: post #39
hnthr_w_y wrote: post #34

Earlier quoted context omitted.

I'm looking for a job where this is feasible. And I'm not even being sarcastic, I'd take a pay cut for such a workflow.

Seems like maybe shops have a tendency to get stuck in one extreme or another, either shoving crap out the door or else excessive concern with prettifying minutia.

I’ve literally never seen the latter: I think companies that do that just disappear. The former though is a great driver: Let your debt pile up sky high because it doesn’t matter as long as it lets you make more money in short term vs dealing with it.

you may say it’s short term thinking, but if you’re optimising for investment, that’s the right thinking. Make money now, you can always move it elsewhere that makes better use of it.

It’s not what I personally agree with, but just my observations so far

Re: Garbage collect your technical debt (2021)

#48

Post by yarekt »

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

Ouch, right in the feels.

I’ve come to realise that there’s no valid business case for dealing with tech debt early, nor adding tests to an existing project (bar some special circumstances / legacy change, critical outage, etc)

It’s like a lot of things have to be aligned for “good” development practices to reap benefits, most shops are much less organised, and a bit of chaos and early/quick iterative shipping will always yield better results.

Having said that, my core belief is still that if you take care and do things properly you’ll go fast in places where all other companies get bogged down

Re: Garbage collect your technical debt (2021)

#49

Post by yarekt »

noisy_boy wrote: post #25

I do opportunistic collection - when I am working on a feature, and spot opportunities for a refactoring/cleanup in code that is more or less directly related to the code I'm touching, I will keep making small incremental changes and keep testing them until my feature is implemented and the cleanup is done as well. I also ensure to not make a breaking change while doing this e.g. no change to the user facing api sign…

Consider a case where every non trivial refactor ends up in several rabbit holes, requiring lengthy meetings with lots of people to discuss, and many disagreements about direction. And in light of that the trivial refactors start to feel like you’re taking a bucketful out of a tsunami.

What ends up happening is it’s much more impactful for the team to just focus on shipping what they can, partly because they don’t have the tools/procedures/experience (anymore) for dealing with tech debt in this context

Re: Garbage collect your technical debt (2021)

#50

Post by benji-york »

physicles wrote: post #32
WalterSear wrote: post #26

Earlier quoted context omitted.

"I'm confused. When I greenfielded this app, several thousand commits ago, I took half the time you've already spent on this feature. You said you were a senior engineer!!" True story. Twice.

I’m lucky that I don’t have a boss like this, but I’ve asked myself this question recently. I’ve been with the same company for almost eight years working on the same code base, which I and another dev greenfielded. I know it very, very well. I’m often dismayed at how long things seem to take these days compared to when we first started out. Am I getting slower? Lazier? So far, I’ve identified the following factors:…

I wish I had more than one upvote to give you for this post.

> I’ve asked myself this question recently.

I suspect both are true. There are real complexities that have grown around you and working in the same way on the same stuff for so long has caused you to habituate to a few inefficiencies. I suggest shaking up your world view a little and seeing what falls out. There are probably a few big gains you could make.

Good luck!

Post reply on HN