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

First, I would focus on doing something visible for the client: show that you can deliver, and do it as quickly as possible. This means: do not try to understand everything, do not try to get a mental model of the whole thing. Once you get some buy-in from your customer and people within your client, you will have more flexibility to negotiate things, and be able to use most of the technical advices you were given.

If the customer is not willing to enter this kind of discussions after you showed you could deliver, I would just walk away if you can.

Raise your rates. If you just took the gig, you'll have to wait a bit. But you should price your work such that whether they say yes or no, you have no regrets.

Expose the problem. Start inventorying the issues. Track them in the same way that you track other work. As you do things that the client has requested, track real vs actual time. E.g., "This change took 12 hours; if the code base were clean, it would have taken 1."

Estimate the size of the problem. Talk in terms of technical debt. E.g., "Module X needs 120 hours of work to bring the code to commonly accepted standards of code quality." The clients are thinking, "We have a system we paid $1m for, so it's an asset worth $1m." Expose the debt and they will have a better idea of the true value of the code base.

Look for opportunities to declare tactical bankruptcy. Once you have numbers, you can show that some portions of the code base will be cheaper to rewrite than to clean up. Help your clients make good financial decisions about when to just toss and rewrite particular parts of the code.

Don't let them make you crazy. I'd recommend something like a kanban board to track work and strictly limit work in process. This system is probably a mess because the client is insane. Develop some very clear, very firm boundaries that keep them from driving you crazy as well. If you are lucky, they will, over time, learn from you to behave rationally about software.

But that situation is different from the one we discuss here.

I do not know more information about ohmygord's project, but I basically want to point out to consider non-technical side of it. For example, people in the same team may not technical, and/or think maintaining existing solution is simple. I was in similar situation before, I was lucky to happen to select right strategy to deal with the situation.

1. Make sure you have a rock-solid contract in place with the client that will ensure that you get paid, get paid well, and get paid often. Receiving a check in the mail makes it easier to look at the code. If your payment terms are anything like, "payment-upon-completion of ...", or, "paid net 30 after invoice", or anything like that, you simply won't want to work on the code.

2. If "soul-crushing", "depressing", or "makes me want to hang myself" are phrases you'd use to describe the code or your state of mind when looking at it, then go into this project knowing that you're not going to last long. There are people who genuinely enjoy working on stuff like this. You aren't one of them.

3. Everybody that says "rewrite" is dreaming. It is impossible to rewrite something that large without breaking something and spending too much money. Re-factoring a function is doable. Re-factoring a thousand-line file is doable. Re-factoring part of a database is doable. Re-factoring all of it all at once is starry-eyed fiction. Not gonna happen.

4. But, if taking ownership of this code base is something you want to do, then add re-factoring time in to your agreement with the client -- something like, "20% time spent replacing bad code" -- and focus on the tiniest little ugly thing you can find, and re-factor that. Start on it, don't stop until it's done. Keep it in small bite-sized chunks.

5. Make sure you're getting paid for time spent just getting familiar with the code base. If you work with it long enough you'll actually get pretty familiar with most of it, but you want to do that on their dime, not yours.

6. Get help. They surely realize by now that they've got a mess on their hands. Talk with them about whether or not you can bring on additional help. If they flat-out refuse, run. (That is what killed my work with my client; I wanted to move into a position where I managed a junior programmer and focused on code rewrites and higher-level stuff; they refused, I quit. They wanted an employee, not a contractor.)

7. Version control and a sane bug tracking system (Mantis isn't horrible) are must-haves. If they don't have these, again, make sure they pay for it.

Dealing with a code base like this one is as much about state-of-mind as anything else. Either you can handle it or you can't. No amount of advice here will make it more palatable to you if you're not the sort of person that's OK with inheriting a disaster.

Also, even if you've got some kind of agreement in place with the client already, it sounds like you've just now gotten your first look at the code. This, in my opinion, makes it totally OK to go back to the client and re-negotiate. You can open it with, "I'd like to work with you, but now that I've seen the project that you want me to work on, I can understand why this has been a problem for you, and I need to make sure that we can come to an agreement that will work for both of us so that I can fix this for you." (Or something.)

Reluctantly, I took on the project, and started working through it. What I initially estimated would take me a month to untangle ended up taking a year. That's an entire year in the snake pit. And since it was eCommerce, there was serious money on the line when it came to bugs. And there were hundreds that I found.

Just understand the commitment you're making. Make sure your client has the money and the time to make things right. Ultimately, in my project, the client insisted on quick hacks to keep competition at bay, and the code dissolved into a mess. I decided I couldn't keep working with a codebase that was never given a chance.

Understand what you're getting yourself into. Because you're taking over the responsibility of loading a massive crap ton of software into your head for diagnosis. How long do you want to have fragile, crappy, lazy code in your head? Forget about bring superman, you're not going to save a million lines of code, you're going to become the builder of the hacks that work around absurdity. Make sure you understand that.

The burden of broken code you're responsible for, that's always broken in production is like nothing I've ever encountered. Make sure it's worth it.