Reuse, Rewrite, or Refactor?

Question

At work I inherited development of a PHP-based Web site after the consultant who originally produced it bailed out and left without a trace. Literally half of the code is ripped from online tutorials, and there are thousands of lines of cruft that, being incomplete, do precious little. Hardly any of it actually works. I've been trying to pull out the usable components, such as the layout (cleverly intermixed with code), session management (delicately seasoned with unescaped, unvalidated SQL queries), and a few other things, but it's very difficult to force all of this junk into place. Further, I don't speak idiomatic PHP, being more of a Perl user, and I'm supposed to be on this project principally for maintenance, so rewriting everything seems like it would take just as long as wrestling the existing monster back into place.

As an aside, I have literally never seen anything as badly written as this. Welcome me to the world of working with other people's code, I guess, but I do hope it's not this common in the real world to have such gems as these:

• // WHY IS THIS NOT WORKING
• // I know this is bad but were going for working stuff right now...
• // This is a PHP code outputing Javascript code outputting HTML...do not go further
• // Not userful

I'm looking for the best advice I can get here. What would you do if you were in my position?

Edit: Thank you, everyone, for your speedy and helpful advice!

Answer 1

Really it depends on the size and scope of what you're looking at.

As it relates to your scenario in particular, if the work is simple yet the code is broken, you'll probably save a heck of a lot of time just rewriting it. You won't be inheriting any legacy cruft or poor design choices. With respect to web sites, there are tons of frameworks and/or open source solutions you can just map the existing site to without significant effort.

Looking at your code example above, looks like it might also be worthwhile submitting your code snippet to thedailywtf.com. ;)

Answer 2

Maintain the code. It sucks, but the longer you are in the profession (and being tasked with maintenence) the more you come to realize that gem is not the worst thing you will ever see...

Just learn to work with what you have, and provide as much benefit as you can. Of course, if you have really evaluated the code indepth, and still come to the conclusion that you could write it from scratch faster than fixing it, provide the (planned out) timeline to your boss and see where it goes.

Answer 3

Explain the problems to your manager, indicating that the support costs are going to continue to mount unless you remove the technical debt in the code. Recommend that he go for a rewrite as soon as possible, using the existing system as a template for the features, i.e., 1-1 replacement as the goal. Since a significant fraction of the development time is figuring out what you need to do, this shouldn't take as long as the original. Having a competent developer on it might mean that it will only take a fraction of the time.

Let your manager do his job -- compute ROI on the replacement project -- and make the decision.

Answer 4

I guess as you know all too well there is no simple answer here, Dealing with legacy code is one of the most frustrating things in our industry but something most of us have to deal with all too often. What i would recommend before you go any further is to make sure you understand the exact scope of the project breaking it down into must haves and desirables. You can then focus more closely on the most important areas first. In terms of the choice of reuse/refactor/rewrite etc then this will really depend on how bad the code is in the first place and what the future of the code needs to be.

Answer 5

Explain to your customer that the previous consultant may have been in over their head. The code is not manageable and needs to be rewritten. If you desire to untangle this mess then explain that the cost will be more than to rewrite from scratch. I've had to do this before. It is easier to rewrite most of the time.

Answer 6

I'm not a fan of refactoring for the sake of re-writing/refactoring, as I work in a mature, legacy environment. It's more important to see "what changed" in the source history, than to see beautiful code. Most of our changes are tied to bug reports or approved "change requests" with formal requirements. But here I'm talking about code that basically works, where yours does not. So in your case, when dealing with code that doesn't currently meet requirements (ANY requirements, past or present), I'd say go ahead and rewrite.

Answer 7

Everyone inherits bad code from time to time.

What you've got here is a fairly classic example of what I've seen in the past (I've actually seen worse). While I can understand the desire to rewrite (and indeed, if ALL of the code is this bad, you should be looking seriously at that option) - your manager may not go for that, or at least not immediately.

Either way, you'll be dealing with this for a while. I'd clean up as much as you can, or - if this is customer-facing - push the security issues. If the code is as bad as I'd suspect from what you've posted, it's probably littered with such treats as SQL injection, plus a smattering of CSRF and XSS. As such, if you're using it for anything that needs to be secure, you can make a good case for "improving" it.