You know the kind I'm talking about.<p>A huge lumping monolith of spaghetti with barely any tests, class hierarchies a mile deep, and a list of dependencies that can make a grown man weep.<p>Written by a self proclaimed "genius" 15 years ago with junior devs patching features on top of it since.<p>What's your story? How did you deal with that mess? Are you still on that team?
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.<p>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...<p>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.<p>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) ;)
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.<p>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 .
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.<p>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.<p>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.<p>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.<p>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.
I loathe Apache Airflow. Rather, I love the application but I hate that data engineers just read one or two examples and write whatever they want, and because Airflow is fault tolerant, they keep using their shit code. The last place I worked with had these idiots writing Airflow code, and they had no idea how to write any software. But since it was working they'd made themselves indispensable and the CTO was also in denial. The engineers maintaining it were some of the most egotistical and incompetent people I've ever worked with. After working with Airflow I realized how amazing Django is, because it enforces such developers to stick to its way of doing things. I love Flask more, but I see now why someone would enforce Django at an organization.
I'm a bit late to answer but anyway: I worked with people who created electronic devices like payment terminals. They were knowledgeable with electricity and coding firmwares, but not with good programming practices.<p>They wanted to modernize their source code though. The result was a mixed mess of old C++ (pre-98), and assembly language. Like C++ classes with assembly language inside.<p>Also I had to teach them how to use Mercurial, thank god I didn't went with git (which I love) or it would have been way worse. I also wrote a lot of Python packages to handle the dependencies, clean code, and do everything to ease their job.<p>They were fun guys though and we had good times working together, I miss them somehow.
Fun fact:<p>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.<p>"index_old_test1.php" etc. was normal and the codebase went back to 2005.<p>It runs (unless things have changed... which is unlikely) on 3 physical servers - HAProxy, Apache2 and MySQL5.<p>No backup or failover/redundancy.<p>Oh, and more PII / GDPR data than you can shake a stick at - unencrypted at rest and in transit between app & database servers.<p>Everyone shared the same root password (no SSH keys!) with boxes listening on 22 via public IPs.<p>Thankfully the contract was a short albeit terrifying experience.<p>Never seen anything so bad in nearly 20yrs of tech.
The worst codebase I ever worked on was my first project ever lol and it was made by me! It was my first job and I was proud because I had spent a couple months teaching myself how to code and DS/Algs and got a full stack role.<p>I had to write a shared components library and yeah.. it went about as well as you can imagine. Thankfully the senior devs would tear my code apart and over the six or eight months I owned that project I learned a ton and made a v2 that was far better. From what I know it was used for another couple years since I left.<p>So yeah I’d say the worst code based I’ve worked on were my own code. The next project I was team lead on a login service. Again I had no idea what I was doing and someone gave me clean code and clean architecture books. Those changed my attitude a lot too.<p>It’s fun building code now, because any time I deal with old legacy code or so called spaghetti I understand why it’s that way and accept it. I write clean interface on top of it and within a couple months that old system is totally replaced by something that works well and is easy to test.
Mine was huge Java monolith that ran (and maybe still runs) part of the foreign exchange system that banks use to trade currency.<p>There were 8 layers of abstract classes with only one concrete class at the bottom.<p>There was a whole half-assed quasi-functional almost-but-not-quite-turing-complete language in XML for parsing legacy binary files.<p>There were unit tests, but they modified the dev DB so you needed to manually reseed it after every run (defintely no CI).<p>I spent months trying to refactor some of the more afwul bits. Not sure I actually made things any better.<p>I still shudder.
My favorite description of a bad project was "dogshit fractal"- at every level of detail it was dogshit. Functions, file layout, architecture, build system, even the business case.
I was with a medical equipment manufacturer for a couple of months. The codebase doesn’t have any consistent styles, and has tons of warnings and linter suggestions lol, no tests no and barely any documentation, it was a pain in da a* to work on that codebase… all the frameworks and packages used were pretty old and out of dated (this one though is understandable considering all the approvals required form FDA and stuff)
Worked for 5 years old a ColdFusion codebase that is still in use for a large SaaS. 1 Big monolith, no tests, all procedural code and changing any code would break something somewhere else.<p>But honestly now I work on a typescript monolith thats moving to microservices and its probably worse than the ColdFusion code base. I'd rather work on the ColdFusion codebase.
Nested code with no tests or docs and devs are afraid to fix bugs. That's where i coined the term "Fear Driven Development". The code is so mess such that no dev wants to touch the code. when they do touch, something is surely broken.
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 place that sort of thing. They agreed but wanted it done in 3months, told them impossible need more time than that, they wouldn't agree so I walked.