Ask HN: I just inherited 700K+ lines of bad PHP. Advice?

Hey RobAley, thanks a lot for the tool recommendations... also big thanks for the person who suggested SONAR+PHP, will definitely look at that too.

I was planning on using phpdoc and xdebug, but haven't ever looked at XHGUI. Is it significantly different from xdebug? At first glance there seems to be a fair bit of overlap in terms of functionality.

There is a fair amount of overlap in what they do, the main variation is in the interfaces and how the information is presented. I tend to use one or the other depending on the task at hand. They're both of good "pedigree", xdebug has been around now for about 10 years I think and so has a good amount of history behind it, and XHProf which XHGui is based on was developed by Facebook and used against their code base which is probably somewhat larger than yours (though hopefully better written!). At then end of the day they're both pretty easy to get up and running (and of course they're free), so I would suggest giving them both a test run and see which you prefer the feel of and which better suits your needs in terms of the information it gives you for your task. Given that you look like you will need all the help you can get, you might even end up using multiple tools like this to get as much insight into the code as you can. If you do, be aware that they can often interfere with each other (or so I've read, I've never tried those two on the same code base at the same time) so you might need to deploy them on separate virtualised but identical environments with the same code.

Edit: Just to say, I usually use XHGui for profiling existing code and code in production, and xdebug for profiling changes to code and code under development. But thats just because thats how the tools "feel" right to me, and there's no reason why you can't do both with both.

I remember a client asking for vtiger once. I downloaded the source, and didn't even get to installation before I fired the client.

I really, really feel for you on this one.

The only thing I can say is: Make a beachhead of clean, working code. Slowly work your way out. Make it very clear to this client how much of a favor you're doing them, and give them meaningful status reports (even if all you did is rewrite the glue between to pieces of code).

First of all, make sure the client and you agree on what the long-term strategy is. Then get buy-in for a first step in this direction.

If the system is as bad as you make it sound, the long-term goal has got to be a complete replacement of the existing codebase. That will usually require as much effort, and thus money, as writing the existing version did. (Experience shows there's is no reason to confidently assume different.)

Then, explain how to get there without doing a (hopeless) complete rewrite in one big bang:

First, you need to make a set of decisions for the new code you're going to write, i.e. the language, framework(s), architecture, whatever you want to new code to be based on.

Next, you try to modularize the existing system so that you can replace one tiny part.

That's going to be really, really hard - modularizing a systems after it's in production always is. Don't do it all at once: If you've isolated some small piece of so that there's a clear interface (based on a programming language API, a database interface or (my favorite) some RESTful HTTP API), rewrite that small piece using your new technology stack and integrate it with the existing monstrosity.

Once you have done that successfully for some small aspect, you have some sort of proof that this approach can work.

Then, over the next months (or more likely: years), rinse and repeat.

This is a hugely expensive thing to do, but that shouldn't come as a surprise – after all, you're replacing the organs in a living body while it's running a marathon on its last breath. An MBA should understand that the additional cost is because this strategy drastically reduces the risk.

You can explain to the customer that they can try this out using just a small part, and decide whether or not they want to continue afterwards. Point out that you're going to start with those parts that produce most of the existing pain. Explain that you're helping them to return to a situation in which they have fewer bugs, can introduce new features quickly and easily, and best of all, that the end result will be a system that's modularized, hopefully ensuring that they won't run into the same situation again.

If they expect you to do magic, i.e. maintain the mess and magically turn it into a good piece of software without being allowed to actually change it significantly, get out of the contract as quickly as you can.