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

Every programmer that has ever existed has said and felt this exact thing. It used to really bother me as well. Then I realized that the world is a messy place and I would need a stronger stomach if I was going to watch the sausage being made. Don't refactor because it violates your delicate sensibilities about code - that's a great way to waste a lot of money and get yourself fired.

Greenfield development or maintaining a legacy code base that isn't complete shit is a luxury. Leave things better than you found them but you have to earn respect/influence before you can start attempting sweeping changes.

PS - https://blog.codinghorror.com/the-ten-commandments-of-egoles...

I feel like this is how most legacy code bases are made.

> Never giving me a chance to justify it, or even reading the commit messages, to understand why it was done that way.

This is a surefire way to re-introduce bugs that were fixed ages ago. Understanding why things are the way they are is the first order of business when working within a legacy code base. Was it done this way because the obvious way has a non-obvious edge case? Was it a requirement from the users? Or was it just the fastest way to do it at the time?

You have to have a certain mindset to effectively work on legacy code, and this isn't it. Most more junior developers I've known have a "rewrite" oriented mindset, meaning they don't know how to work within the constraints of what exists and refactor piecemeal. It's a hard to learn skill, generally learnt the hard way.

This is good advice, especially on the communication part.

It's always tempting to use the word "rewrite" but most of the time you just want some assurance that your code doesn't break things, and a rewrite is usually overkill.

I would suggest you to add in additional time for refactoring into your new feature development. This has 2 benefits - you're not rewriting the whole project, just the parts that are relevant to what you are currently working on, and you're still pushing out features.

It sounds like most of your refactoring work is in code isolation / scope management and creating tests.

Don't fix things just for the sake of fixing them. Let new features, bugs, or necessary performance improvements drive your changes. Keep your changes small and focused. You need to ensure that you're delivering business value with each change, rather than embarking on an overwhelming, open-ended task.

This is critical if you want the business to support your effort. It demonstrates pragmatism. It will shrink the scope of your changes and make the problem less daunting. You can prove to your boss and your coworkers that it's possible to fix the problem without slowing down new development efforts.

Be careful how you express your dissatisfaction with the code. Many of the people who wrote it are likely still there. Approach every change from a positive angle, so you don't alienate your peers. Get them to help you make the changes, and help them to learn how to become better developers. Don't assume they don't know better; they may have inherited a mess too, and they may have been under pressure to deliver quickly at any cost--or maybe they just don't know any better, but want to improve.

Read these books:

_Working Effectively with Legacy Code_ by Michael Feathers

_Refactoring: Improving the Design of Existing Code_ by Martin Fowler

_Clean Code_ by Uncle Bob

These are invaluable resources. There are many others, but these three are particularly germane to your situation.

What you describe is called technical debt. https://en.wikipedia.org/wiki/Technical_debt

A strategy of unethical developers is to make themselves relevant by producing a lot of features while drowning the project in technical debt.

This often happens when:

a) stakeholders are not technical.

b) their strategy is to have an early exit (like an acquisition) before the problems caused by the technical debt materialize.

c) they can compensate for the technical debt hiring an army of thousands of developers.

I would say it is a management problem. And like all management problems, unless you can fix that, your best option would be to spend your peak productive years in a company that cares.

If you want to take issues to management, tread very lightly. First of all, your challenge will be to present the problem while not seeming depressed, irritated or pessimistic, or heavily criticizing others. Try to sell the idea using a positive twist, like increased productivity, robustness, etc. If that doesn't work, just start interviewing.

---

If you decide to stay, just start creating tickets from all the technical debt. Make sure to include details like commit links, and objective information about how it is a problem. Then:

- link bug tickets to tech debt tickets.

- link incident tickets to tech debt tickets.

- if a task requires a tech debt workaround, create a separate ticket for the workaround and link it to the tech debt ticket.

This should create some sense of visibility around the tech debt. It will likely won't work anyways:

- Some people feel smarter and empowered when they deprioritize tasks.

- The only ability of uncreative managers is to say no. Saying no makes them feel useful.