Hacker News Reader

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 wrote years ago, but that's frequently how things look after years of updates and feature creep. Everyone on our team has code like that, and when new guys come in and point them out, we just sigh and say "yeah it would be great to rewrite that knowing what we know today". But budgeting time for that is not easy.

Edit: Also, like others said, I think you need to adjust your expectations. Working with code like that is life, and you should appreciate the fact that you, with your outside perspective and youthful energy can make a change for the better. But it's going to involve lots of refactoring and test writing.

The "Legacy Code" book referenced in another post is a great overview of this. I'd say of all programming books I've read, it's one of the ones that are most relevant to my day to day work.

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.

FYI, the Legacy code book is: Working effectively with Legacy Code by Michael Feathers. Its useful, I also strongly recommend it when you're feeling overwhelmed by a large sprawling code base.

https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe...

>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 implemented and the original design didn’t scale well

Well said. There are many possible causes behind a poor codebase, and it's rarely useful (and almost never persuasive) to go into finger-pointing mode. The issue for the OP is: from the business's perspective, is the poor code a problem? If it's not, can they live with continuing to work on this code in this job? And if it is: what's the next step, and what can they contribute to making it happen?

I think it's quite rare for the prototype to not end up in production. This is even true of the Trans-Siberian Railway [which meant people died].

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.

> Then give them a few options with trade-offs.

I had (well, I’m in the middle of it, so have) to fix a few bugs in a project that are the by-products of a deeply flawed architecture. I came to my boss and explained a handful of ways that I could potentially solve the problems, and made it really clear that the best way to go would be to completely redo this one part. He agreed with me, though he wasn’t happy about how much work was involved. ¯\_(ツ)_/¯ Hopefully your managers will appreciate you giving them options.

> Hopefully your managers will appreciate you giving them options.

Take this one stage further, taking solutions to your manager is worth 10x taking problems to this manager.

For example I work with a codebase like this. It is over ten years old, have multiple people working on it, many learning or of differing abilities. Frameworks have been used and over time their limitations come to light. Often people have been band-aided something to save time, because they have been under severe time constraints. Large swathes of it are almost superseded but not quite. The purpose of the software has subtly shifted over the last decade.