Live data from Hacker News

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

news.ycombinator.com

131–140 of 346 posts

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

#131
post #104

Start writing tests, change no production code. You need to understand how it works (by reverse engineering its behavior with tests you’ll learn this) and you need to verify your changes don’t accidentally change existing behavior unless the existing behavior is verifiably wrong, and hey, you may find instances of this too, but don’t start making changes until you have a suite of tests that can spot behavior changes.…

Definitely this, though I’d say the first thing to address is good observability. Are all errors being logged, with stack traces? If it’s a web service, are errors rates and timings for all endpoints tracked?

Next, the deployment process. Are tests run on all deploys? Are there canary deploys to minimize impact when bad code goes out? Easy rollbacks?

After that, I’d address the dev environment. Can you run it easily locally? Can you easily attach a debugger?

After that, add end-to-end, integration, then unit tests, in that order. Only then, once you understand the code well, and have it nicely instrumented and tested, should you consider significant refactors. By that point, you may even realize that a lot of it is good enough and rarely touched, and doesn’t really need to be refactored.

If any of the above steps are already well covered, skip them. And don’t spend all your time doing this - talk to your manager(s), try to get buy in to spend say 1/3 of your time on the health/quality of the code, 2/3 on features/bug fixes/etc. Justify WHY - in this case it sounds like the code would be hard for anyone but the original author to modify with confidence, to make sure the code scales past this one person without the product becoming full of bugs and instability, it’s necessary to devote significant time each sprint (or whatever) to improving quality. Can frame it as “original author was just trying to ship quickly, and could keep track of all the hacks because they wrote them, but to bring more people onto the project it has to be made safer/easier to modify for non-experts”. Maybe wait until you’ve been there a month or three before you start pushing this.

At the end of the day, the code doesn’t have to be perfect, it just has to be decently easy to modify with reasonable confidence. Tests should catch most errors, monitoring should quickly catch the rest to minimize the impact. Work towards that, over time, without killing yourself trying to sneak in refactors that your manager(s) don’t know about.

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

#132
Read this about rewriting: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

It's possible to rewrite but you incur risk when you do. Add tests and then refactor. Measure twice, cut once.

Or move. It's possible the person hates what they wrote and just escaped. But do the best job you can while you're looking for a better role. And focus on business value.

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

#133
post #98

Earlier quoted context omitted.

Yes. "Human Resources" is quite literal. Management discuss allocation of resources (i.e. engineers) to teams, open REQs (requisitions) for resources, etc.

Where I work, "Human Resources" is just in charge of benifits/payroll/etc. Assigning people to projects is done by the resource manager, a completly unrelated posistion.

By the 'resource manager'. Point stands.

But, no place has HR assign resources.

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

#134
post #16
post #3

Are you working at my company? Ok, more seriously: that’s the way existing code is about 90% of the time - it’s the reality of working in our field. It may or may not reflect on the original developer. Maybe they were learning a new framework. Maybe they were rushed. Maybe it was originally intended as a prototype but ended up in production. Maybe the requirements have grown or changed significantly since it was impl…

If you’re going to take this to management, I would not bad-mouth the original developer. This. If there are deficiencies in the code base, focus on those, their effects, and the gains from fixing them. Blaming people is rarely a good idea, for many reasons. If the original dev worked on the code base for a long time, they're probably already aware of them. God knows I'm all too aware of the deficiencies in code I wr…

This is a great reply, and I want to second a lot of the points brought up.

Adding on, the original developer is almost certainly aware of definciencies in the code. My guess is that they are largely a result of rushed deadline, changing scope, and feature creep than they are the result of bad engineering. When you need to get a new build out at 11pm because you have an angry client on the phone, it can be tempting to say “I know this is bad practice, but I’m just throwing this in the controller to get it working for now. I’ll fix it in the morning.” Especially at a small company without solid engineering practices, this happens enough times and you’ve eventually got an application with no meaningful organization or architecture.

Having been in charge of an app that started to look like this, i know that I would have loved a new dev to come in and say “I want to familiarize myself with this codebase by writing some tests, and seeing if there is any basic refactoring I can do. Where is a good place to get started?” The original developer probably wants to write those tests himself, but either has too much on this plate, or doesn’t realize how much time he’s wasting by working on a fragile codebase.

All in all, as other posters have mentioned, stay positive, and see how you can clean up and improve your little corner of the world.

One last point, I might take this as a small red flag. Don’t quit over this, but keep it in mind. If management isn’t willing or able to put engineering practices first, or to let engineers do their jobs the way they’re supposed to be done, it could signal other issues.

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

#135
post #95
post #79

So you're the new guy that's been assigned to this project...possibly at the request of the current developer who desperately needs help...possibly because it's the project that existing staff don't want to work on...possibly to learn the project so the current developer can be moved to other projects. Every software company has these projects and many developers have been in your position. As long as the software is…

> The fact a new resource (you) has ... I am not familiar with this lingo. Why exactly is the OP a resource? Is this usage of "resource" common in business speak?

That's pretty normal in the industry.

Had a client where the employees where stored in a table called "resources". Also felt very much like a resource there..

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

#136
post #95
post #79

So you're the new guy that's been assigned to this project...possibly at the request of the current developer who desperately needs help...possibly because it's the project that existing staff don't want to work on...possibly to learn the project so the current developer can be moved to other projects. Every software company has these projects and many developers have been in your position. As long as the software is…

> The fact a new resource (you) has ... I am not familiar with this lingo. Why exactly is the OP a resource? Is this usage of "resource" common in business speak?

Yes, developers are resources, what they produce needs to be of enough value to make up for the pay you supply them with. Which is why refactoring and rewriting is almost never on the agenda for management, because it often doesn’t bring in value.

In rare cases a piece of software is so bad, that rewriting it makes sense, because it means you’ll save development resources in the long run, but in my experience that’s rarely the case.

The best developers write good clean code with low dependencies and tests for things that matter, most developers aren great developers though, and things can almost always be made better, even if they are.

So it’s really about time vs results. A good example is RPA, it’s some of the most simple code around, but it’s often very hard to get it to take over 100% of a process. Your developer spends a few days to take over 80% of a manual process, but the last 20% would take your developer months of small adjustments.

That’s often not worth it, and refactoring is often the same.

If the system isn’t slow, and you can still add new features to it without breaking anything, then it’s not worth a refactor.

This doesn’t just apply to developers by the way, I manage a lot of different types of people, but they are all resources that I need to fit within my budget to meet the goals given to me by my management, who in term see me as a resource to meet their goals. We’re all cogs in the machine.

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

#137
Consider that you might be wrong. It takes a lot of work to understand a code base. I've seen many young developers spend a short time looking at some code, fail to understand it, throw up their hands and claim it's a mess that needs to be rewritten. Put in the time to make sure you know what you are talking about before making a fuss. I've refactored a lot of other people's code in my career. If someone else wrote it then it pretty much always looks bad at first. Then again there is plenty of genuinely bad code out there.

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

#138
This is the reality, don't expect every code base is clean and well organized. I have come across the same situation for a couple of times in my career. I felt disappointed at the beginning, I wondered how high-paid engineers could write such shitty code, but quickly I found it's actually a very challenging job. To understand the code base was like playing puzzle games with debugging tools. I had invented tools with some new stuff I just learnt to trace and visualized the program, or wrote scripts to clean up the code. Eventually I became the owner of these projects, and refactor the hell out of it.
Post reply on HN