What's the worst codebase you've ever worked on? • Hacker News Board

zoozla wrote: post #6

moremetadata wrote: post #3

Something that was managing the largest construction project in the world amongst other building projects. Had plenty of devs on it, not junior but highly expert. Gave them 12months of my time to achieve their objectives, but it became clear the code was a can of worms, fix one thing, something else broke because of too many different coding styles. Told them it needed a rewrite from the ground up, standards put in p…

Sounds like bad codebase compounded by a toxic team. A lethal combo.

Bad management who dont understand programming, which is sadly replicated across many companies, and then people wonder why its so easy to get hacked. eyesroll

Re: What's the worst codebase you've ever worked on?

#67

Post by rich_sasha » Thu, Feb 23, 2023, 2:05 PM UTC

How very odd; all the posts in this thread are by new accounts, who posted in a very suspect post about Upwork. These posts also hardly make sense and look like they were written by GPT-2 or similar.

Nothing wrong with this thread as far as I can tell, but, if I could summin supernatural beings with a mere mention, I'd call @dang .

Re: What's the worst codebase you've ever worked on?

#68

Post by kypro » Fri, Feb 24, 2023, 2:26 AM UTC

I've realised that many codebases I considered "good" in the past I now consider to be kinda "bad", but more notably there are codebases which I thought were "bad" in the past which I now view with more appreciation.

Codebases are kinda like cars. What's a "good" car? Is it a car with a large trunk and comfortable driving experience, or is it a car which does 0-60 in 2 seconds? The answer depends a lot on what you want to do and what your preferences are.

There are obviously objectively bad codebases, but I think a lot of codebases I considered bad in the past were just built in a way I wasn't comfortable with or was optimising for something that it didn't appreciate at the time. Ever noticed how it's common for JS devs to hate Java projects, and for Java devs to hate JS projects? I think that's probably because they're optimising for different things and are used to working on codebases which incorporate those priorities.

But to answer your actual question, my core languages are PHP, Node and Java. By far the worst codebases I've worked on have been the Java ones because they tend to both be larger, older (full of legacy code) and more likely to be over-engineered. Crappy code in a PHP project is probably more common, but generally you can just strip it out and refactor without much consequence. In Java projects everything tend to be much more interconnected which makes refactoring difficult.

Age of a project, the number of short-term contractors and junior devs on the project, and a lack of high-level architectural discussions within a team tend to be the largest collating factors to a bad codebases in my experience.

Re: What's the worst codebase you've ever worked on?

#69

Post by kypro » Fri, Feb 24, 2023, 2:32 AM UTC

comprev wrote: post #4

Fun fact: Over 50,000 procedural PHP5 files under zero revision control, without a non-production environment to test on, power one of the largest "grey area" e-commerce platforms currently online. The type of place where you can resell medical pills which claim to cure every illness under the sun. "index_old_test1.php" etc. was normal and the codebase went back to 2005. It runs (unless things have changed... which i…

Lmao, this sounds like every 2005 PHP project.

I think part of me would actually kinda enjoy this experience just for the nostalgia factor. I got surprisingly good at making changes in prod without causing downtime...

Re: What's the worst codebase you've ever worked on?

#70

Post by Eatcats » Fri, Feb 24, 2023, 1:22 PM UTC

I was working for one production company making products out of concrete, and they had this SCADA system. They had 5 factories and 5 versions of the same software. This software was made by one company, but as factories were built in different times, software was evolving as well, so when I joined the company there were 5 factories with different code bases, that were doing basically the same thing. Oldest software was written in VB6, newer in .NET 1.1.

The problem was that making changes on all factories required making changes in code in 5 codebases, and it was impossible to merge them into one because of subtle differences how the production lines were working. Also it was impossible to run this software locally, so only tests you could do on live production environment. Imagine testing your software, there is a bug, and you just wasted 2 tones of concrete...

My solution for this problem was making a checklist of all the things that need to be changed and checked before changing, codebase by codebase. Also keeping the changes in SVN helped a lot for implementation reference. Good commit messages and comments in code were essential not to drown in this mess.

In the end, I hired an employee, taught him the ropes and "sold him" to this company. He works there till now and does exactly the same thing (8 years and counting) ;)