Learn More
Resend Email
9
IntrusionCM
4y

*revving chainsaw noises*

Today I started nuking leftover project code.

At the end, some projects shrunk by roughly up to 40 % .

Can anyone explain to me why programmers have such an awful hoarding syndrome?

Why do you keep shit that might unleash complete havoc cause it hasn't been touched since years and noone knows id it still works?

It's like having a leg with gangrene and keeping it cause "it doesn't look that bad".

For fucks sake. Clean up and remove shit when it's not necessary anymore.

Reason why I did a bloody gore massacre in nearly a dozen projects... After all the rework of networking, it's finally evident which projects have a bad / nasty behaviour of "fucked up" connection handling (HTTP 1.1).

And when my gory massacre removal goes life, I think 25-35 % of persistent connections on the loadbalancers will vanish. Maybe even more, since some very nasty stuff was in some projects.

Like "let's implement monitoring without having any clue about how monitoring works and even less clues about how TCP/ HTTP works."

*Bangs devs heads on table*

Stop. Doing. Stupid. Things.

For fucks sake.

:@ :@

rant

rm everything

keep your filthy hands away

hoarder syndrome

stop doing stupid things
Favorite
Ranter
Comments
  • 1
    4y
    Like commented out or just dead ends of live code?
  • 0
    4y
    > Why do you keep shit that might unleash complete havoc cause it hasn't been touched since years and noone knows id it still works?

    That happens when you don't write test (we don't do that here; no idea why). It's the fear to brick ancient depends.

    Story time: I once refactored old af code and everything seemed to work fine at first. Unfortunately, I fucked an unused internal API, causing issues later on when someone used it.

    Did I introduce a bug in the core? No, but I did change some logic. I largely refactored small "findX" methods which basically, instead of returning null if it doesn't find anything, returned a new object based on the search input. This obviously invited a "Test the application manually and fix NullPointerExceptions on demand" situation.

    Truly a shit show.
  • 1
    4y
    @N00bPancakes to be precise, both and an additional part:

    self referencing services.

    Since the selfwritten monitoring solutions don't have consumers as in Rest API provided endpoints are unused and obsolete... But call themselves for some very profound dumb reasons...
  • 0
    4y
    @ApparentlyHuman That is imho the weakest argument....

    If it get's ripped out and things start to break, you can at least pinpoint where and why.

    That's better than the very dangerous illusion that it might be unused but still functional.

    Especially in your case, changing is API breakage. I'm talking about removing.

    Two very fundamental different things.
  • 0
    4y
    Beeing doing the same for the last week. Also a massive code reduction, around 50%.
  • 0
    4y
    @IntrusionCM I'll admit I have left some commented out code here or there at times 'just in case' something goes wrong / I replaced that code and all hell breaks loose the next day or something and I want to put it back in...

    But .... yeah that hardly ever happens so I sorta quit doing that after a while.
  • 0
    4y
    @N00bPancakes If it's a line of code or a block of code and the ticket doesn't get closed before the removal... I'm fine with it.

    It's just this annoying behaviour that people use a mothertugging VCS...

    For everything.

    Except for the most obvious and Most important function: to revert accidential code changes. If it isn't used, remove the tons of lines of codes, let the motherfugging frigging static code analyzers and test suites do their fairy glitter magic and if it really breaks later, revert the changes necessary from the god damn VCS.
  • 0
    4y
    @IntrusionCM fair point, but it's not always that easy. In my case, it silently crashed without an error in sight. The developer had to play the old "guess where it is" game across several components, each written in different languages (yes—glued together in one project), whilst questioning whether the JVM is the one silently crashing (niche field; don't ask). Not gonna lie, I still feel sorry for him. Poor guy debugged that beast of a project.
  • 0
    4y
    @IntrusionCM Yeah I agree, makes no sense to leave it in there in case it needs to be reverted... when there is a thing just for that.
  • 1
    4y
    > For fucks sake. Clean up and remove shit when it's not necessary anymore.
    "YoU cAn'T, tHeRe Is No BuDgEt fOr tHaT." I know we have a few projects at the company that are complete shitshows, but I can't refactor 'em because it wouldn't make us money.

    > Like "let's implement monitoring without having any clue about how monitoring works and even less clues about how TCP/ HTTP works."
    You'd be surprised how often you have to do shit waaay outside your comfort zone. We had this freelancer who was OK, but he believed async/await is for multithreading, and thus never used it for offloading the CPU while waiting for PLC feedback. Yes. the code is full of while(true) loops.

    > Stop. Doing. Stupid. Things.
    You'd have to realize first that you're doing stupid shit.
  • 0
    4y
    I'm still surprised at how often I see experienced devs remove code by commenting it out and committing, in case we need it again later.

    If only there were versioning tools for this. "It's hard to find"NOT IF YOu wrote proper commit messages~
  • 0
    4y
    @HerrNyani again.

    We're not talking about refactoring.

    We're talking about removal of APIs and not fully removing all code parts after the API removal.

    Refactoring != Removal.

    And the second part... Of course you need to know that it's shit. Which you can't when you don't question yourself.

    Your example makes this obvious... How could he not ask your team and why has your team not helped him?

    The longer this rant gets the more I'm getting angry.
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment