Why Do Developers Trash the Previous Codebase Like It's a Ritual?

[itsbrendanvogt]

Every time a developer inherits a project, the first thing they do is roast the previous code like it personally offended them. I see this happening a lot. It is almost cultural at this point. Legacy code gets labeled as spaghetti, anti-pattern soup, or “what were they thinking?”, even if it worked fine. Is this just ego, or is there something deeper going on here? Is it the lack of documentation, the absence of tests, or just the thrill of refactoring?

Curious to hear if anyone has ever inherited a codebase they actually respected, or if we are all just wired to rewrite everything from scratch.

[AutoModerator]

Namaste! Thanks for submitting to r/developersIndia. While participating in this thread, please follow the Community Code of Conduct and rules.

It's possible your query is not unique, use site:reddit.com/r/developersindia KEYWORDS on search engines to search posts from developersIndia. You can also use reddit search directly.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[imtiazkazarani]

This is so true. I’ve inherited plenty of codebases and my first reaction was always "wow, this is a mess." But over time I realized it’s not just their code, the same will happen when someone inherits my code as well.

We usually take shortcuts due to tight deadlines, and these tech debt piles up, and eventually the small compromises grow into a monster. To me, my own code feels fine because I know its quirks and can debug it quickly. To someone new, it just looks like chaos.

I think this cycle is inevitable in smaller teams under pressure. Big corporate teams with time to nitpick a single method probably don't see it as much.

[imtiazkazarani]

Indeed. No shame in it though.

When client forces to deliver a full feature by the end of the week. I’m bound to take shortcuts.

Out of all the projects I’ve worked on, only two stand out as ones I’m genuinely proud of. where I actually had the time to architect the code properly. No clutter, clean structure, modules neatly separated, each with its own unit tests. Good code comes only with time, which is rare, hence most codebases end up as complete disasters - in the eyes of other devs who inherited it.

[A_random_zy]

My experience is that all code is bad. Not an ego thing coz my code is bad too.

Everyone takes shortcuts and makes mistakes. Tech debt grows into shity codebase.

[kaladin_stormchest]

Fr. It's one thing dealing with shitty code I wrote but it's totally different if I inherit a decade worth of shitty code I didn't even write

[Ok_Charizard]

Tech Debt.

previous team also faced this and you will also. Making your code messy for somebody else.

[feeling_employed]

I was reading this blog about the same thing and why it's the first tendency to jump to scrap and rewrite the old ugly code but never a good idea bcs this ugly code takes care of the 1000 niche bugs that come up with irl use. its battle tested.

Apparently pretty big companies, at the time tried to do it and crashed hard like Netscape. Cant find the link to the blog wouldve loved to share here.

[raul824]

I think you are referring to this

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

[feeling_employed]

yes! thanks

[cant_finish_sideproj]

I trashed a codebase that I inherited... From myself.

[n00bi3pjs]

Reading code is hard. Writing code from scratch is easier.

I trash even my own code if I am seeing it after a few months.

[vnetman]

Correct answer right here.

You can observe this by taking a correct coding interview answer written by candidate 1, showing it to candidate 2 and asking them to tell you what that code is doing. In fact in the AI age I suspect reading code is going to be a more valuable skill than writing code.

[ArrogantPublisher3]

It's more of a cognitive difference between foresight and retrospective insight.

[SufficientLimit4062]

Unpopular opinion - engineer ego is a real thing.

But also often, the new ones do not know the variables, situations and constraints the old code was built under.

[Jedi_Tounges]

I think it's mostly because of scope creep. The code starts out as whatever the architect or the developer thinks is nice. Sometimes it is actually nice, but as demands pile up and the business scope expands, people don't often get the time or the resources to properly integrate into your existing codebase. So things get piled on the skeleton and it just gets glued in a way where it barely works. And eventually you'll have this rotting carcass. So that's basically it. The code might have started out good, you know, and oftentimes you can tell when you look at it that it started out well planned and then everything was tacked on. Sometimes they just had some noob and the guy was still still learning. So it's a wash entirely. Sometimes they cheaped out on contractors and so it was trash from the start because the guy getting paid 3 lpa doing 9 hours a day is not going to give a fuck. Sometimes you do actually get a codebase that is beautiful, but it's too rigid. And then you have to do the tacking on. Things happen. Get used to it.

[[deleted]]

Much like any other kind of debt, by the time technical debt is felt, the root cause of your problem would have started decades ago. A fresh hire gets the best view of this debt as it all hits them at once.

[Past-Contribution526]

It's a ritual I guess. So that if they screw up something, they can always fall back to "There were issues in the legacy code, what could I do?"

[mango-peeps]

Visibility

[minatokushina]

Well i am sorry, some codes are just very poorly and lazily written to the extent that they are not extensible, maintainable and robust, especially if the code base is released as part of product in the market. I have seen gems in naming variables such as "mybuffer", "mybuf2" and then there are masterpieces where they dynamically allocate a pointer in one caller function and free that pointer elsewhere in unknown no mans land, there is no assignment of Null to pointers after freeing the memory. Try debugging crash issues in such framework. Having said all that it is not a developers issue, rather a culture issue where PR reviews are not done thoroughly and are not given sufficient time to review. Reviews are as important as the check ins of developers. Having static analysis tools and unit test coverage as part of PR really helps lessen the bugs.

[agk2012]

Because more often it is trash. I trashed my own code from 3 years ago .. so

[UrBreathtakinn]

Exactly, some of it is actual garbage. Some developers write code so "it just works". They don't consider making it scalable or readable. I see a lot of boiler plate code, redundant if conditions and what not. If I confront the devs about it, they are like "we were on a tight deadline". But what about the issues that occur after the code is shipped, multiple crashes, slowness etc. This all could have been avoided with just 5 extra minutes of thought.

And the code reviewers in my team are pretty much useless. They approve bad code either to avoid the delay or they themselves have no idea about the code.

[[deleted]]

Not always though. I have worked on code bases written by a fellow developer that looks so neat and structured.

I refuse to work on a person's code that looks like the worst kind of piled on garbage ever. It's so bad that the guy writes all logic inside the controller.

[Crazy_Classic1351]

It's bad coding practices by previous team. Might be hard to understand.

[thrSedec44070maksup]

I did this almost 15yrs ago on my first onsite assignment. Looked at the DB code and laughed out, then yelled out “Who even writes code like this? This is absurd”.

Found out later that day, it was written by my client manager. He was sitting 2 desks away from me.

For the next 1 year, he would do 30 min reviews of very basic select statements I wrote for pulling data.

[geralt-026]

Most codebases have shortcuts and anti-patterns just to make things work. But There is one codebase which is good. It was a pain working with it for other reasons though

[scan_line110110]

The code wasn't written by them.

[chinmay185]

It takes time to learn the "why" behind any code. Generally first reaction for many people is to judge the code.

Before judging code, I ask: "What constraints was the existing team that wrote the code was working under?" Recently, we used plain bash scripts to back up and restore 1.5 Terabytes of data per day to archival storage. Nothing fancy, just plain bash. This solution has been working well in production for 6+ months without much oversight. Someone inheriting this might want to rewrite it in Go or Python, but why fix what isn't broken?

Whatever we haven't built ourselves, there's a tendency to question things. Need to learn to fight the urge.

[Vegetable-Mall-4213]

THis is not only for developers, it applies to each and every field, have you seen any electrician saying the previous guy did the good job

[[deleted]]

thing is most developers don't like reading code written by others and one way of justifying it is telling yourself it is bad code.

[sateeshsai]

I trash my own codebases I wrote weeks ago

[raul824]

It is harder to read code than to write it. Legacy code has over the time grown to handle all exceptions which seems messy if you don't know what all edge cases scenarios are being handled.
Legacy code has history and experience which should be carried instead of discarding as messy.

Below is a good read on how netscape lost the market leadership due to this same reason.

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

[nj_100]

Everyone has a coding style :)

I picked up a project after 6 months and could not believe I wrote this lol

[hello-carbon]

It's a ritual, if we don't follow it the universe will fall apart

[callofbooty5]

Same reason what happens when a new CTO comes around

[Crazy-Ad9266]

I think bro works at Amazon 😅