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

that's a real hard decision to make...

problem i see here is, that the framework is used and fixed for a long time so there a lot of knowledge went into it and the quality for the running projects is obviously acceptable. so if you rewrite it from scratch with all the requirements you know - you can be sure that you will forget something that already worked (hard one to explain that to a customer - or your boss ;))

refactoring it - it think - is also a hard task since there is only one guy who really knows the connections within the code - who does not want to change it...

there are three options:

• live with it
• convince the guy that refactoring is needed so everyone can use/maintain it not only him
• convince the management that a rewrite is needed but this will get the one who is against a rewrite/refactoring really upset

either way you put it - it's a bad situation for everyone... since with time passing by the one responsible for the framework will have to deal with it himself and then it is probably too late.

Answer 3

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.

Answer 4

On a small level, yes: provide a new version of a function, verify that it works with the new as well as with the old, remove the old. That's often enough faster than refactoring the funciton itself. But on that level, it's refactoring :)

The strategic cost of a rewrite virtually always exceeds refactoring.

You cannot deliver. You have to maintain the old version while you develop the new. If finances say you have to kill the rewrite project, you have achieved nothing - your working code base is in a bad shape as if nothing was ever done. Probably even worse, since all changes were kluged on because "we'll throw that away when the rewrite finishes anyway".

---

Yes scenarios where the rewrite is cheaper CAN be constructed:

• the original code base is so spaghettied that any local modification breaks seemingly unrelated features.
• You have a really great new team, much better than the old guys, but they have no experience with the existing code base, and the existing code base is a mess, or in a language they don't know, or something like that.

---

Still, experience shows that code is bad for a reason, and it's not always the coders, and when you don't identify and change the causes, the rewrite will be an exercise in repeating history.

Answer 5

Rewriting is very risky. You will replace old well-debugged code with new code which is to be debugged yet. This will introduce a whole lot of bugs and you'll have to fix them. It's better to refactor gradually - first understand in very detail what some part is for, then refactor it. This way you replace less code and lower the risk of introducing too many new bugs.

Answer 6

To add to what's already been said: Try and get management buy-in. There are benefits to the bottom line when you refactor - man hours for programming new features will go down over time rather than up, leading to reduced cost in salary and possibly server costs as well. If none of your management understands why refactoring is worthwhile and is going to make you happier doing your job, are you working at the right place?