Garbage collect your technical debt (2021)

Post by yarekt » Tue, Jun 11, 2024, 2:58 PM UTC

WalterSear wrote: post #61

yarekt wrote: post #48

Earlier quoted context omitted.

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

I'd argue that there's definitely a business case for frequent and early refactoring - it just needs to be refactoring worth doing in the first place. IMHE a most code gets touched rarely, and some parts get touched all the time, so refactoring needs to be strategic if it's going to have any utility. This also argues for ongoing refactoring - addressing pain points as they arise, while they are fresh in people's mind…

I think it goes back to experience. If everyone involved has suffered at least once, they’ll be keen to spot issues before they cause pain. both developers and managers.

So therefore my current reasoning is this sort of thing can’t be taught or explained /shrug.

I’m currently on a quest to teach/explain this now, so depending on how that goes I may change my mind, but i’m not holding my breath

Post by yarekt » Tue, Jun 11, 2024, 3:04 PM UTC

0xDEAFBEAD wrote: post #57

yarekt wrote: post #47

Earlier quoted context omitted.

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

With regard to "excessive concern with prettifying minutia", I'm thinking of e.g. code reviews where people spend significant attention going back and forth on minor stylistic issues. Another example: I remember a coworker reviewing code I wrote many years ago. I came up with a solution that was reasonably simple and workable, but wasn't the "right" way to do it. My coworker complained, I pointed out various reasons…

I can relate very much, from both viewpoints!

I sometimes catch myself discussing “correctness” in PRs because it’s important to know what tradeoffs you’re making, and whether a neater/simpler/better solution exists. So yea, sometimes my suggestions can be misinterpreted as blockers.

I have since learned that giving actionable feedback is the trick to smooth review process, as well as trusting the authors (in a way). Their implementation may not be the way I would have done it, but I have to ask myself “will it still work?” as a basis for pass.

But I digress, I can see what you mean in your original reply, and agree, that weird “arranging deck chairs on a sinking ship” does indeed happen

Re: Garbage collect your technical debt (2021)

Re: Garbage collect your technical debt (2021)