It can also put you in an awkward position -- especially if the prior developer has a grudge against their code being rewritten -- as any bugs that come up can then be blamed on the rewrite effort, whether or not that was actually the cause.
Spaghetti code eventually collapses on its own, as every change starts taking longer and longer than expected, as well as introduces more and more bugs (and fixes for those introduce more, and so on). Once this starts happening, that can be the impetus to actually do a real rewrite effort, but one with a business case, management and hopefully the other developer(s) behind it.
Until then, a rewrite is a lot of effort that, at best, if you do a great job, is basically invisible (beyond the code level), and at worst either becomes a scapegoat for or the cause of many other problems.
I don't work at a small company but refactoring and especially rewriting code is difficult and error prone. It's a crazy thought but in many cases, it can be better to just leave the legacy code alone. It's all about ROI of your time and the opportunity cost of what you're working on.
If you're going to be making lots of changes to a specific part of the code base, then it very well may make sense to invest in improving it so r hat you can move faster after. But if the code isnt going to be modified much, it may be better to just get in, make the changes you need, and get out.
As a mid level developer, nobody is expecting you to come in and rebuilt the thing immediately. Focus on learning it well first.
This should at least give you the opportunity to contain technical debt to the most complex requirements.
To say "everything is complex therefore we cannot rewrite anything" is pretty implausible and mediocre.
"The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it." - Joel Spolsky
You don't want to live in this hell during the rewrite, trust me!
(Oh, and another tip: if your management authorizes the rewrite you propose easily, it means you are SEVERELY UNDERPAID... the time of good devs always costs to much for rewrites to be worth it, unless the dev cut a really bad deal on hiring)
Chromium for instance has code from the original KHTML written in the 90s, most of that remaining code is reasonable and makes sense today. If it didn't someone would have replaced it.
... and also don't think that your "double of original estimate" is anywhere near a maximum of what it can take to actually make the code base better and functionally correct.
It is often true that someone with very strong domain knowledge may have had this project in their head for a long time, and one day, all-of-a-sudden, has to code it all in a rush. I have had this, where external factors shifted the companies priorities.
In this case you can 'brain dump' a lot of code very quickly, get it functionally correct and make intelligent judgement calls about the threats of edge cases... especially if it is internal company software.
However, coming at the problem from cold, without the benefit of this knowledge requires significant analysis and engineering effort to get equivalent results. So tread very carefully.
But yes, add tests
I am not familiar with this lingo. Why exactly is the OP a resource? Is this usage of "resource" common in business speak?
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.
But, no place has HR assign resources.
Had a client where the employees where stored in a table called "resources". Also felt very much like a resource there..
It is the culture of the company who makes the difference.
Its not art, it's a job. (to me)
Every software company has these projects and many developers have been in your position. As long as the software is still functional and is profitable then management don't care how bad things are under the hood (try explaining it to someone who only sees a working/functional UI). The fact a new resource (you) has been assigned suggests it's still a valuable project.
Unless management are the ones giving the go-ahead on the rewrite then I wouldn't bother. Rewrites are very risky, time-consuming and make no money for the company. However long you think it will take...double it. You're a mid-level developer, a rewrite needs to be planned and led by an experienced senior developer.
Your best bet might be patience...try ride it out and hopefully be moved onto other projects. In the meantime you get experience. It's how you handle the adversity that could prove more valuable.