Legacy projects are cancers of this profession. I would not wish maintenance of legacy code(written by someone else) on my worst enemy.

Today's clean code will be tomorrow's legacy shit.

@jespersh And now let some requirements change, plus unforeseen edge cases that need to be addressed, and more robustness handling. Rinse and repeat several times, and you have a successful product with ugly code.

Everything will become legacy sooner or later. Not just your code, also the language, its standard library and 3rd party libraries.

The question is, can we build our systems in a way that makes it easy to throw them away, in part or in whole, so they can be easily replaced? Basically, how close can we get to "development without legacy"?

I wish theres such a thing as software inspection, where a group of devs have a sole job of looking at a companies software and they can either approve its continued use or legally force them to make a new version

We are all writing legacy code. The difference is HOW SOON will it be called legacy.

@sleek ah, like cars and planes need to inspected whether they're still in safe condition. Would require a lot more standardization to be feasible, but why not.

I share this pain , i know as we sell chips to customers if bugs are reported in legacy code we have to solve it. But boy does my blood boils to see a 3 year old code branch
I don’t feel like engineer i feel like a fucking maintenance guy !! Also it’s not like I introduced those bug. In that case it would make sense

I always delay legacy issues until it’s from big customers like google or Samsung.
No matter what management say new feature implementation is always priority for me

@Jilano I have short hair now 😁

@Jilano ya, true

@Jilano it's kind of triggering, isn't it :) I know, I don't like it too. I'm planning to return to the city temporarily next month, so.. Fingers crossed :)

Admission: I am writing some shit code right now.

Result: I will have to maintain this later...

Like a huge part of my day is reading other peoples code and deciding if it is shit enough to have to rewrite or good enough to reuse.

Years ago I "worked" on a legacy PLC system with really scary ladder logic. It somehow got itself into 2 states at once. I didn't have time to work on this POS system. However, I noticed this dual mode issue. So I asked a colleague to "fix" this code by putting in a line of logic that would force the mode into one mode when it detected this problem. This solved 2 problems: it kept the system running, and it got management to call my colleague about future issues on this system.

@Fast-Nop and today’s bad code will be...

“I know I am writing bad code know but I will clean it when I have time”
Narrator: He had time but he didn’t have stomach to look at the shit he created.

I would

@aviophile Today's bad code will be tomorrow's "best practice".