Should I give up on refactoring this and plan a rewrite? [closed]

Question

I'm tasked with maintaining a modestly large system (~60k LOC of non-Moose OO Perl). I'm starting to question the wisdom of refactoring it rather than rewriting it. I know this question has been discussed at length, but the situation is unusually complex and has several elements that point strongly in opposite directions, hence my question. Sorry for the verbosity of the question; it's as concise as I could manage while getting the whole picture across.

As the system stands, it's abstractions are quite poor at encapsulating anything cleanly as evidenced by frequent reliance on action at a distance, copious use of if/else blocks with intimate knowledge of objects of a type unrelated to the module at hand, and a dependency graph which looks like a social network. This, I felt, was bad, but could be refactored.

Test coverage is spotty. This is, of course, fixable, and needs to be fixed before the refactor. Of course, in a system like that, tests need absurd amounts of scaffolding, which makes improving the test coverage more arduous, but still, it's hardly impossible.

And so I'd planned to spend a lot of time slowly bringing some order to the chaos. Hard, but doable, I thought, and the system does work well enough for business purposes, despite all it's issues, so it must be doing something right. And "everyone knows" rewriting something like this is a recipe for disaster.

But recently, I discovered that some of the most vital and poorly written parts of the system have deeply seated and serious design errors that go all the way into the data schema. The entire methodology has major problems (this is consensus among those who have worked on it, not just me) and the workarounds for that probably constitute half the code in that part, though it's so poorly written that there's no hope of telling them apart from business logic. The code is too convoluted for myself (I've only been working on it for a few months) or the prior primary maintainer (of several years) to understand fully. It also has less than 10% test coverage.

No one is confident that they can completely and correctly describe what that part accomplishes, much less how. Getting good test coverage for this part is all but impossible when the code is indecipherable and the requirements it meets aren't well understood. Refactoring without test coverage isn't right, nor is it remotely practical in a system of this size, complexity, with such pervasive problems (and dynamically typed makes automated discovery of the impacts of a change impossible).

Leaving this and dark corners untouched is not an option due to constantly changing business requirements.

The only practical way out of this that I can see starts with re-defining the system requirements on a business level and making a commitment to meeting that spec and risking any breakage that no-one anticipated. I know it's a bad strategy but I don't see alternative. If that is chosen as the path forward, it seems much of the benefit of refactoring goes out the window, which leaves me seriously questioning the virtue of even attempting to refactor this.

This leads me to the specific question: Is refactoring a bad strategy in this case? Answers backed with actual experiences are strongly preferred as I think the theoretical aspects are well established here and elsewhere.

Answer 1

Been there, done that. The legacy code I currently maintain is the cumulative effort of several non-CS folks (engineers) who set out to get their program(s) to achieve the required functionality with close to no regard for maintainability, flexibility or scalability.

But what worked for me may not work for everyone.

In such situations it is often helpful to list all of the relevant criteria and weigh one's options. I tend to ask myself the following questions:

• Does your employer see value in a code rewrite/refactor?

  It is all too easy to get carried away with Doing the Right Thing, but do so only if you have your employer's buy-in.

  My experience - if the business doesn't see value in the rewrite/refactor, then you really should put this activity on the back-burner. Focus on documenting the existing code and gaining better insight into how the code works before attempting to write/modify/test anything as and when required.

• How often will new updates / feature requests be added to the code?

  The more often such activities are undertaken, the stronger your case becomes for a refactor/rewrite.

  My experience - it is sometimes more valuable to the business that you work with the existing code and apply well-documented patches to it with minimal modifications.

• The code will need to perform function X after n months. How capable is it today?

  This is applicable if development is ongoing. Look at the long term and see what the code needs to be able to do and how well it could address those needs in its current state.

  My experience - Refactoring sometimes doesn't cut the mustard because the current state of the code is grossly inadequate

• How long will it take to implement the changes envisaged?

  The estimate should include the time required to understand, document, implement, test, validate and release your modifications.

  My experience - it really takes a lot longer than one might imagine initially, especially testing & validation.

Answer 2

First, read this article on why not to rewrite from Joel Spolsky. Then I suggest concentrate on writing tests, which will be needed for rewrite, refactor, or normal maintenance. Once that is done, revisit rewrite/refactor question.