Is there a point where cost of refactoring outweighs the cost of re-writing?

Question

We have some really shocking code touted as a next generation framework at my current place of employment.

Thing is, there is only one person of this opinion and that is the guy who wrote most of it. The rest of the department are of the impression it is badly coded, a pita to debug and just a bit naff in general.

The guy that wrote it has a pretty influential position with management so they are on that side of the camp.

We have highlighted (genuine) concerns to management but obviously they're not willing to put more time in to a project that doesn't directly contribute to the bottom line.

There are several applications deployed on this framework so any refactoring will need to encompass those applications.

The whole thing is so intertwined that we cant just rip out an implementation of a particular class and rewrite it that way so even simple changes to core api mean a large project.

It does however have 3 years in live deployment and many bug fixes, corner cases and boundary conditions catered for.

Do we rewrite in parts and try to refactor that in given that it would be several large projects, refactor over time which is likely to take another 3 years to get it in to shape or do we just rewrite our specific requirements on top of an existing framework?

Answer 1

Rewriting something is almost universally a bad idea -- you spend months working, with nothing to show for it until you've finished. And that assumes that you don't fall prey to the second-system effect, and that you actually do finish.

Refactoring is almost certainly the right answer. I don't have any experience refactoring PHP (I do C++ and C#), so I can't offer any specific advice. You have to proceed with baby steps.

• First, identify the parts of the code that offend you the most. For me, in C++, this is global variables.
• Second, make small refactorings to remove one problem at a time. In order to avoid breaking older clients of that code, you might need to put a facade in place. Either you can put a new facade on the old code, or you can put an old facade on the new code.
• Third, and most important, unless you're really confident, make sure that you've got a solid set of unit tests for the code you're about to refactor.

But: don't drop everything to rewrite the code. Refactor gradually. It'll slow you down a little bit, but you'll still be delivering value as you go along.

See this article that will help you explain Technical Debt to your management. It'll also explain why they don't seem to care.

Answer 2

The advantage of rewrite is that you can take in account all the new stuff in analysis phase, create a model more adapted to the current needs. On the other hand, if it only badly coded, not badly designed, there's no point in doing complete rewrite. Just sanitize/refactor the code.