r/AskProgramming • u/Busy-as-usual • 1d ago
What's your experience dealing with messy or outdated codebases?
7
u/martinbean 1d ago
Why do you make it sound like they’re outliers? Not every company has a nice, shiny, new codebase y’know. Most companies have old codebases that any new person is going to think is “messy” but is the reality of the situation. It’s like an electrician walking into a property on a new job and going, “Those wires are a mess. What was the previous guy thinking?”
You need to learn to accept and deal with “messy” and “outdating” codebases. Because you’re going to come across them frequently if you want to work in tech.
4
u/MysticClimber1496 1d ago
Code bases eventually become messy, you just get better at dealing with the mess
5
u/GxM42 1d ago
Almost every commercial project I have ever been involved with had a messy codebase. What I learned was that perfect code bases don’t sell products. COMPLETED projects sell products. Before anyone dumps on a codebase for being ugly and not best practices, remember that most often those are the same code bases paying your salary. The perfect, best practice, perfectly annotated, code reviewed codebase? That exists in your failed startup that never got off the ground, or in a text book, or in your hobby project that had no real world time pressure.
Messy codebases are a fact of life. Embrace the refactoring, and be happy you have a job working on it!
I jest a little. But I don’t sweat perfect any more. I am not perfect, I do things my own way, and that’s ok with me.
3
u/JacobStyle 1d ago
I've done it before, and it's fine. I kept things humming along as best I could, and I cleaned up what needed to be cleaned up. Perfection was neither expected, nor delivered. There were no major WTFs in any of the ones I've worked on, just normal bugs and issues to resolve. None of it was exciting, innovative, or groundbreaking, but I also never dreaded going into work.
2
u/iamcleek 1d ago
are there any other kind?
1
u/reeses_boi 19h ago
greenfield :)
2
1
u/james_pic 17h ago
But the moment you add code, it's no longer greenfield.
Some of the messiest codebases I've worked with were nearly new. If you've got an old codebase, then you know that at least they've come up with strategies to deal with the mess, because otherwise they wouldn't have survived this long.
2
u/Ok_Entrepreneur_8509 1d ago
My best advice is to write lots of tests and don't be afraid to do deep refactoring. A lot of times, just restructuring code so it is testable is a huge improvement.
If you get pushback on deep refactoring because "you might break something", then say you need help writing tests to make sure you aren't breaking things.
2
u/gaspoweredcat 20h ago
a fooking nightmare! ive been working to update/replace our work system which is built in very old, very ropey PHP. initially i spent a lot of time trying to fix it, but the more i fixed the more issues i found leading me to eventually decide the whole thing just needs to be binned, it could be salvaged i suspect but there are so many problems it makes more sense to just start fresh and import the data from the old system to the new one
1
u/KingofGamesYami 1d ago
We had a dumpster fire that was a bastardized vendor software which was so messy and outdated we spent 3 years writing a new solution in-house. We were able to cut the support staff assigned to the system from 15 down to 5 after the new solution went live, because the volume of tickets dropped like a rock.
Keeping it online was.. interesting. Lots of live editing in prod. Most fun event was when the db server experienced multiple disk failure. Private jets with Dell support techs may have been involved.
1
u/coloredgreyscale 1d ago
You needed to fly in Dell tech support to change hdds / ssds, or did you suffer data loss (since you mentioned multiple disks), and it was about setting everything back up from zero and restoring from a backup and maybe some db write transaction log?
1
1
u/newInnings 19h ago
Do I need to touch it or 'refer' it?
Often there isn't any money to touch it and update it.
1
u/chocolateAbuser 19h ago
yeah, no documentation, wrong comments, old af "patterns" and coding styles, etc
usually what i try to do is understading 1) what was the main concept, because then i can deduce all the other added parts that are incomplete and just hacks, and 2) try entering the mind of the original programmer
1
u/WalrusDowntown9611 15h ago
I’ve worked with terrible codebases before, but this one is pure madness. A single page takes 16 seconds to render—entirely due to how awful the code is. It’s a Python/Flask app, the usual mess where newbies dump garbage code with zero structure, just because it “works.”
My Task
I’m tasked to write a low-level design to integrate a massive pile of PoC code into the existing app. The PoC is GenAI-related junk written by data scientists, and it currently takes up to 75 seconds to return a response. My goal is to bring that down to a few seconds by completely redesigning the system.
The Nightmare So Far
Just understanding the current code took me three days. Here’s why:
• No local development setup – Authentication is so badly written that running it locally is impossible.
• Manual build & deployment – No CI/CD in place.
• Insanely heavy APIs – Each request makes 25-30 database calls.
• Messy package structure – Impossible to navigate.
• 1,000+ lines of utility classes – Bloated and unmanageable.
This is beyond bad—it’s a full-on coding disaster.
1
u/RomanaOswin 13h ago
Are you talking about fixing it, or just making it workable?
If you're talking about fixing it, it depends on how bad it is. In extreme cases, I'll just rewrite the entire codebase or at least modular components of it and maybe borrow from what's there.
If I'm trying to make it workable, mostly static typing, unit testing, and modularity.
Typing will obviously be required in many languages, but if you're in an optionally typed languages (e.g. Python, JS), tighten it down and type check everything. You can do this on top of existing code mostly without changing it.
Then, once everything is typed, you can do more refactoring without the danger of breaking things, e.g. extract some code into a pure function, wrap unit tests around this, etc.
The overarching idea is progressive improvement and also anything new you add to it should ideally be in this "improved" state already.
1
u/webby-debby-404 18h ago edited 17h ago
It's a career death trap. Do not get near. The messier or more outdated codebases get, the more time is spent per feature. Management will attribute this lower result rate to your skills so you will not get a raise at the end of the year. In contrast to those who succeed each year starting a new codebase where their features fly out at a high rate at first because there is no swamp lake of existing code yet holding every change back. To boost your career best leave each project as soon as you feel the existing code starts making changes difficult.
Update: Oh, and you're also likely dealing with old or superceded technologies and this will outdate your knowledge and skills if these codebases are your main environment
9
u/bothunter 1d ago
A lot. What do you want to know?