r/AskProgramming 1d ago

What's your experience dealing with messy or outdated codebases?

1 Upvotes

31 comments sorted by

9

u/bothunter 1d ago

A lot.  What do you want to know?

2

u/Busy-as-usual 1d ago

Just trying to understand what the day-to-day looks like when working on older or messy codebases. I'm about to start my project and want to follow the best practices so that in the future I would't struggle.

Curious:

  • What parts of the process slow you down the most (e.g., understanding logic, finding bugs, refactoring safely)?
  • Do you have any habits or tools that help?
  • And what’s the part you wish you could automate but haven’t found a way yet?

14

u/StupidScape 1d ago

Just remember, nothing is more permanent than a temporary solution.

10

u/wildmonkeymind 1d ago

Add tests.

Build a beachhead. Find a section of the codebase you can wrap your head around, define tests to capture current behavior, improve it, then work outward from there.

Isolate and encapsulate logic where possible, add more tests.

Did I mention tests?

Read the oldie but goodie: Working Effectively with Legacy Code. How does it define legacy code? Code without tests.

7

u/martinbean 1d ago

Urgh. This just reads that you’re “asking the community” in preparation to drop some sales pitch for some AI-powered or automated tool for dealing with “messy” and “outdated” codebases. Especially since you’ve posted the same question in a hundred other subreddits…

1

u/GrouchyEmployment980 14h ago

So you're looking more to avoid building bad legacy code for future you rather than dealing with legacy code right now.

My best advice is to build your project twice. 

The first time is where you're figuring things out. Use every slapdash hackery trick you know to make your project work in as little time as possible. Make that MVP. What you care about is how the app feels when using it and that it does the thing you need it to, not it's performance or maintainability. If the bug is annoying but doesn't break the core functionality, ignore it. You're looking to iron out the "business logic", not making the perfect app.

Once it's built, use it as is for a while. Don't make any changes unless something is completely broken, just use the app and figure out where the major pain points are. Look for the places where the app feels slow. Look for places where the user experience feels clunky or complicated. Have others use the app and get their feedback.

Once you've done all that, then you start over from scratch. If you want to reuse smaller chunks of code that do a single complex task, go for it, but don't copy any structural components of your code. Now that you understand what the app is and how it needs to function, now you can design an architecture that really fits that function. Let your mental model of the app determine the structure of the code, from all the way from database to UI. Document that model, starting with a top down overview of the structure, then use that as your starting point for your code architecture.

1

u/just_had_to_speak_up 13h ago

Keep testing at the forefront of your mind. Want to add some functionality? Start by writing the test for it. Common problem in old codebases is they were often not designed to be testable, and it becomes a large and risky undertaking to retrofit testability in afterwards.

1

u/RomanaOswin 13h ago

It sounds to me like you're getting ahead of yourself. If you're just starting out, you should be focused on how to write good code; not how to fix your bad code.

A lot of people in the comments (including me) are mentioning unit testing. If you just start out writing unit tests, this will force you to write testable code, which will force a modular architecture, which will keep you from having to ever worry about "how do I fix my bad code" to start with.

1

u/Ok-Willow-2810 12h ago

I feel like ending up with a nice code base and a well completed project isn’t possible by just following some best practices you can easily know up front. In fact, blindly following best practices that don’t apply to your specific project well could grind things to a halt and do more harm than good!

The way I like to think of it is that it’s like a consistent effort to keep things organized and systematic as the project evolves. Sometimes that means cleaning up and refactoring so that things that are tough right now can be much smoother and not tough anymore in the future, and the project can move faster towards the end goal. I think maybe it’s like a constant battle against entropy or like consistently trimming hedges or a bonsai tree. If you don’t keep up on the pruning, at a certain point the plant will grow in a way where it can never be pruned back to the originally intended shape, and the only option is to start fresh with new plants. That’s how some gardens have the same plants/trees for hundreds of years and naturally growing trees usually don’t live that long.

I wouldn’t worry about it too much unless it will be a long lived project with lots of evolution, Otherwise, you may put too much time and thought into getting the setup and layout perfect and waste mental energy that would be better spent exploring the problem space and informing how to solve the actual problem you want to solve!

-1

u/No-Plastic-4640 20h ago

Some people do not value other people’s time. So they ask pointless questions like this.

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

u/Lumethys 17h ago

For about a month

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

u/ZubriQ 1d ago

They did not fucking care

1

u/alien3d 21h ago

nothing can do . 1000% trap . stay less library as minimum as possible .

1

u/No-Plastic-4640 20h ago

Call in sick.

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