How to convince/prove my manager that a rewriting is needed rather than a refactoring [duplicate]

Question

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?

Answer 1

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.

Answer 2

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!

Answer 3

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.

Answer 4

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.