Ask HN: Codebase at my work is a complete mess, what should I do?

I've struggled with this a lot. If you want to talk over the phone or via discord I would be more than willing to be a sounding board. :)

> Recently I joined a relatively small company (50-100 employees) as a medium level software developer. For a while I was very excited about this opportunity. After few days/weeks of getting to know the whole codebase I finally moved to a specific project I was suppose to work on and I found out the code is a complete mess.

Yep

> Often I find parts of code that unintentionally affects other parts of code. Some parts are just copied and left there doing nothing. Even names of classes/variables are sometimes useless and project structure is unintuitive and seemingly without rules. It's spaghetti and relatively big spaghetti (tens of thousands of LOC).

CACE principal at work.

> I started "repairing" the project but there're no tests to check whether my adjustments are correct.



Start writing tests, start motivating other contributors to write tests. Focus on the code that matters.

> I'm so frustrated and depressed by it. The job basically turned into something I hate - I'm just rewriting the code!

You're going to need to work through this and either change your mindset about this or start looking for a new job. I challenge you to do the former and not the latter. This is how 90% of the projects you're going to jump into are going to be. The real test will be whether or not you can thread the needle and make valuable improvements to the code while also delivering business needs.

You can't let this job get you down. I know... it's your vocation, but most of the time people treat their job like a sweet paycheck. Instead you're going to need to treat this as a challenge if you want to get through it. You've identified the problems, now you can either continue to be negative and wallow (bitch) or, attempt to offer solutions to fix them.

The challenge is not so much technical as it is cultural. You'll need to be able to communicate the value of the changes that you want to make. You'll need to change the mindset of the stakeholders of the people on the project to let them know why integration tests are not unit tests. Why, separation of concerns is important and how you plan on doing that. Otherwise, you won't be able to create change and this is the cultural challenge.

The bad news is that this isn't necessarily the exact job you signed up for as an engineer. The good news is that you'll be able to build new valuable skills that are often highly sought after. If you feel like you're a "better engineer" than the current engineer that built it, then you need to help elevate that engineer and the other engineers around them. Otherwise if you become depressive or negative on the job, you're going to have a major negative impact on the rest of the team.

> The person in charge of this project was working on it alone and from the outside it all looks fine and it's working. So this makes the higher people think that it's all just fine.

Welcome to business life. This is how it's going to be a lot. I'm sorry.

> I really don't know what to do. Should I just go and basically say that this person did a bad job? I don't feel very comfortably doing that because (a) I'm a relatively new hire, (b) the person in charge is working there for about two years and (c) I'm much younger than she/he is both professionally and biologically.

No, don't go in and blame the person who wrote it. You always need to "consider the context". It's easy to point at someone's code and call it shit, or to say that a project needs to be rewritten. It's harder to reverse engineer the "why" of how it got to where it is. If you can identify the "why" then you'll have more insight as to how you may be able to fix the problem or address the aspects that may have caused the problem.

> I've already made some comments about rewriting it and the response was basically "ok".

"ok" or in other words, "how are you going to deliver business value for our team". Show them data, show them why having easy to maintain code delivers business value, then people's ears will prick up.

It's your job to manage this problem. If you have the necessary insights, it's on you to fix that. Otherwise move on and don't let it kill you. I know, my job is very important to me as well, you can't make yourself miserable over something like this. It will be far too prevalent in this field.

From super senior dev perspective.

You're not going to be there for the rest of your life. One year is enough. Take it easy. I went through this multiple times, there are lots of places with a shitty code. The worst thing that can happen - you'll will start blaming yourself. But if you just relax and let things go, you'll get salary, 9 to 5, job security. Don't try to fix everything in one day. File stories, fix issues one by one. Eventually you will like it, and this is the real software engineering, the real world.

Yes, there are better places, but you will never know until you get there. So if you can live with it for about a year, it's good. If not, start looking, and remember - it's not your fault, and it's very hard to avoid that. You need to work in a company for a couple of weeks to understand how things are going there. So you new job can be the same or even worse (it also can be better). But there are no any guarantees.

I was in the same situation. It's bad working with poor code, but it's ten times worse having them pile on shitty code every day. And oh my, was it bad. There was no code reuse, if they needed the same sql query in another place, it would just be copied over. Or if there were two slightly different queries based on some parameter, there would be an if/else statement and two separate queries - often with embedded variables (hello sql injection). Routing was one big switch/case statement. Commit messages would often be non-descriptive, like “chk”. Frontend was a special hell, jQuery spaghetti code, mostly single page, with multiple levels of nested ajax callbacks. I tried to be patient and teach them, but the bad practices continued. I even managed to rewrite parts of the backend with a framework and an ORM, but the original devs kept writing code their way. At some point I just needed to protect my sanity and left.

> If you save the world but do it quietly, nobody will know, and they'll decide you aren't productive enough.

I agree, I think OP should find a way to present his work as a "project" that makes sense to management... A good example, someone else in this comments thread suggested that OP could create an API around the legacy core. Creating an API is something that can be "sold" well to management.

A manager if mine once asked the developers what spaghetti code was, and one of the developers gave my favorite answer: "code written by someone else"