Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My manager wants me to refactor a gigantic amount of terribly-coupled, macroed, full of private namespace methods, hierarchy-perverted (even 10+ levels of inheritance) code which hasn't been (indeed) designed with a "whole-vision" concept.

I tried to explain to him that this code needs to be rewritten, not just refactored but he didn't listen and stated explicitly that I need to refactor it.. somehow.

I could dive into all the "dealing with legacy code" books but I think nothing useful would come out.

How can I convince him that a rewriting, instead of a refactoring, is actually needed?

share|improve this question
5  
Your manager might be thinking, how did it get this way in the first place, and what's going to stop it from ending up the same way after years of you rewriting it? –  Scott Whitlock Feb 3 at 13:16
22  
If your boss cannot tell the need to refactor from the need to rewrite, then possibly he can't tell rewriting from refactoring either. Consider rewriting anyway and dressing it up in the words he wants to hear. –  Kilian Foth Feb 3 at 13:17
5  
The question doesn't make it clear what your manager's motivation is for preferring refactoring to rewriting. If you've already told your manager that you think it needs rewritten then your next step relies entirely on why he/she is choosing to go against your advice. Ask them, they might have a good reason. If they don't have a good reason at least you'll understand what is motivating their decision making and you can tailor your explanation to show them why your approach is superior. –  combinatorics Feb 3 at 13:25
12  
He's probably read Joel Spolsky's "Things You Should Never Do, Part I": joelonsoftware.com/articles/fog0000000069.html –  Eric King Feb 3 at 14:58
8  
@tom - isn't that refactoring? The major difference between the two as far as I can tell is that continually refactoring keeps the program running while the code is gradually replaced whereas a re-write means that at no point will the old code interact with the new, meaning that no-one can use the new code until it is near feature-complete –  Matt Allwood Feb 3 at 17:26
show 5 more comments

marked as duplicate by gnat, amon, Doc Brown, Bart van Ingen Schenau, GlenH7 Feb 9 at 15:42

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

4 Answers

up vote 67 down vote accepted

He's probably right.

If the codebase is so monstrous, so gigantically complicated, so difficult to understand... what makes you think you can write something that does the same thing correctly?

Generally a big refactoring is the best place to start - start ripping bits out and combining them into reusable chunks; tidy up the code so its easier to view; flatten the inheritance hierarchy and remove the dangling edge-cases; combine the namespaces; unroll the macros; whatever it takes to turn the big mess into a reasonably understandable system.

You have to understand it before you can rewrite it - otherwise you will just end up with a different mess.

share|improve this answer
6  
BTW, this might help you understand your problem a little better. –  gbjbaanb Feb 3 at 13:53
1  
Big ball of mud, probably right what we have now. Perhaps I'm just incapable of refactoring as my manager wants.. if this keeps going on I should start considering another job.. –  Marco Feb 3 at 14:02
2  
I would say that you need to at least start with the refactor - partly because you need to get more of a grasp of the problem; partly because it might not be so bad once you get going; partly because you will be able to better argue for a rewrite once you have demonstrated you're not just asking due to not wanting to do the refactoring task. A good rewrite is actually harder than the refactor - even though the opposite seems true at the start. Refactoring isn't that hard, it just requires dogged, professional work, but it can be extremely satisfying. –  gbjbaanb Feb 3 at 15:45
6  
Totally agree. Early on in my career I thought rewriting was the way to go, but it never turns out as great as it sounds. Now I strongly prefer refactoring if at all possible. I'd only recommend re-writing in certain cases such as needing (not just wanting) to be on a new tech stack. –  Allan Feb 3 at 16:25
1  
@radarbob this one or this one –  gbjbaanb Feb 10 at 9:03
show 6 more comments

Before you attack the code, I would suggest starting with defining test cases and writing unit tests for them.

Unit tests are handy in a refactoring situation, as well as for a rewrite. They help with making sure that the required functionality stays correct, even when changing the code around.

When you decide to rewrite, you can run the unit tests against the original as well as the new code, making sure that functionality is not changed.

Unit tests will save your ass after multiple rounds of refactoring!

share|improve this answer
6  
Generally a good suggestion, however the sort of mess that the OP describes is likely to be extremely resistant to automated testing. –  Carson63000 Feb 4 at 0:34
    
And I confirm Carson's suspicions: I wouldn't know where to start to write unit tests for that mess.. –  Marco Feb 4 at 10:32
1  
I would be very worried about this. If you can't even identify testcases (read: you don't know what the application does), how can you say that a refactoring (nevermind a rewrite(!)) will produce a functionally equal result? –  oɔɯǝɹ Feb 4 at 19:34
add comment

Re-writing a large project from scratch is often much harder than it looks like at first. Chances are if the code is a mess then the requirements and documentation are in even worse shape. You are going to be spending a lot of time coming up with requirements and figuring out how and why each part of the spaghetti code works. You are going to be constantly asking is this particular behavior a bug, a feature, or merely a convenience for the guy that wrote it.

From your managers perspective and hopefully from yours as well the ultimate goal is to create value for the business. After all as a professional we don't write code just to write code we write code in order to make money.

Something that you may not be looking at is the level of risk for the company and for your manager. If you start working on building from scratch and are not able to complete it for whatever reason the new half completed re-write could end up abandoned. Think of where this re-write would be in terms of priority if there is already a working version and the primary architect leaves in the middle of the project. Would there be a strong enough reason for the company with this upgrade?

Compare that to refactoring the existing code where there is still an actively developed version of the project. If you are no longer available to work on the project it won't be ideal but the risk is much lower.

For a manager to let you do a complete rewrite takes a lot of trust and is only occasionally worth doing even though rewriting is way more fun than cleaning up some one else's mess.

share|improve this answer
1  
You're right, rewriting is also way more fun than cleaning up someone else's mess –  Marco Feb 4 at 10:46
add comment

I've been in the situation where a total rewrite is the best solution. Where the original code is a pile of poorly designed, little understood, hacked up by lazy programmers rubbish.

It's almost always possible to refactor such code from junk to useable code. But the problem is the amount of time it will take. Any series of refactoring's are going to involved extra cost. That being the time and code it takes to make each block of changes work with the legacy code that has not been changed yet. Another kicker is that it's not unusually for the original code to have originated out of the exact same thing you are looking at because someone started "refactoring" it and either did the minimum (read half arsed) or left before it was completed.

Most people support refactoring because their understanding of it is that it keeps things working and can be done piece meal. Therefore they perceive it as the "Safe" option. Mostly correct, but not always. They often choose it because they are too scared to take on a re-write.

Having said all that, you do need to fully understand what the application has to do. If you don't have a clear vision of this. Then it's unlikely that your re-write will be much better than the original.

share|improve this answer
5  
Not so sure. I've been involved in a project recently where we all agree a rewrite would be beneficial.. so we refactored the admin part out, then the DB was re-organised, and soon the main client will get a webby revamp. It'll end up as a huge rewrite with a lot of old code getting reused, but it will continue to work as we make these incremental improvements. I consider this a refactoring even though a lot of new code is being written. I've also been involved in projects, years ago, where a total rewrite was done - nearly bankrupted 2 companies, and didn't deliver the dream anyway. –  gbjbaanb Feb 4 at 8:28
1  
If the code base is horrible but still being used then gbjbaanb's comments are very valid. Taking bits and making them better whilst keeping the beast rolling along at least keeps the company in business. Re-writes are great for the programmers involved but if it takes two years then it'll be out-dated and redundant before it's even released. –  Daniel Hollinrake Feb 4 at 16:35
2  
It all comes down to the developers. A total rewrite can work if the developers know exactly what to do and can do it in a practical time scale. Refactoring can also work on the same basis. However I've seen far more code messes created by bad or aborted refactoring because the developers didn't have the time or self discipline. Self discipline is the is the one key factor when refactoring. Too many programmers don't have it. –  drekka Feb 4 at 23:28
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.