[pudup]

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 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.

[gregmac]

> Rewrites are very risky, time-consuming and make no money for the company.

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.

[cheeze]

Agree with all of this.

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.

[badminton1]

Rewrites are riskier when requirements need to be reverse engineered from the current solution, or if requirements are complex. When requirements are simple, rewriting should be simple.

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.

[cheeze]

I disagree. Rewrites are risky because you're changing code that has been working for some time. It is easy to introduce bugs into a sufficiently complex system when refactoring.

"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

[nnq]

parent is right in that when you realize there's significant functionality that is not captured in the requirements, then it's it's good idea to NOT REWRITE... when you end up reverse-engineering requirements from an existing app, you're standing near a bottomless pit of other horrors you can't even fathom... that's not gonna be an only 200% miss-etimate! think in the range of 10x (order of magnitude) difference between actually and real effort, and how many corners will need to be cut and personal time sacrificed to get from 10x to a "management acceptable" 2-3x overtime during the rewrite.

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)

[badminton1]

I doubt Joel Spolsky was equating legacy code with technical debt in this quote. Not all technical debt is robust and well tested legacy code.

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.

[asmosoinio]

> However long you think it will take...double 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.

[jimnotgym]

> 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

[inDigiNeous]

Somewhere by someone I read that a realistic estimate is your original estimate multiplied by 8. This has proven to be more realistic than previous factors I've seen.

[frobozz]

Increase the time units by one and double it.

[foo101]

> 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?

[eksemplar]

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.

[sidlls]

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

[gizmo686]

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.

[sidlls]

I manage my team. When I discuss projects with my manager and the senior engineering leadership, they will almost always refer to staff as resources, e.g. "team X needs a SOA resource", "team Y needs extra QA resources" and so on. It's distasteful to me; I always refer to my team and other engineers as engineers or by name, not as "resources."

[gregmac]

To balance things out, try casually slipping in the word "overhead" when talking about management.

[oaiey]

I do that. Does not harm. They know themselves :). Good advice!

[lostcolony]

By the 'resource manager'. Point stands.

But, no place has HR assign resources.

[tejtm]

It is a term to enforce the concept of humans as commodity in a commercial environment by the overhead.

[one87]

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..

[iKevinShah]

Yes. It (being called a resource) is common in Big companies where they literally see you as a "resource". This is worse when you are a 'resource' in a big service company.

[oaiey]

No it is not. That is just project management language.

It is the culture of the company who makes the difference.

[jhanschoo]

More precisely, your labor is the resource.

[warent]

Swap out the word "resource" with "asset" if that helps. They're synonyms in this context. "A useful or valuable person."

[neves]

Unfortunately, yes. We are just replaceable cogs.

[cheeze]

I'm okay with this. They are paying me because the work isn't something that I'd do in my free time. I'm okay knowing that others can do my job as well as I can.

Its not art, it's a job. (to me)

[anewone]

I'd rather be a replacable cog than a crucial lynchpin. I prefer to look at my job in the same way. It's much less stressful that way.

[univerio]

Are you familiar with the term "human resources"?

[asattarmd]

What do you think HR is abbreviation for?