There you are, working late for the second night this week. Everyone else in the office has gone home. Most of the lights are out. Yesterday it was trying to copy a feature over to a different section of the site, because marketing wanted their new client to see it there. Today, you have just finished tracking down a globals-related bug in an SQL query embedded in a page script. It revealed itself only after yesterday’s feature addition. You had to search across scores of PHP files to find it. You commit the change, push it to the common repository, and update the bug report so that QA can check on it.

Although you are relieved, you are still frustrated and worried. Who knows what break this fix will reveal? The work should not be this hard.

Your Legacy Application

You were so excited when you got the job. The interviews went well. You clearly knew more than almost everyone else there. The other developers seemed like they really needed your help and expertise. The managers gave you a new laptop and a new LCD screen so you could be as efficient as possible. It was the perfect setup. You were eager to get to work showing off your skills and abilities to make the application sing, and get the project back on schedule.

But then you checked out the code base. It was a mess. It had been architected over several years by mulitple different lead developers, and it showed. There was no consistent pattern to any of the structure. The oldest core of the system was a collection of “include” files that ran several levels deep. Later, someone had bolted on some class-oriented libraries, and third person has decided to try a framework rewrite. All of it was done in a different coding styles, with different naming conventions. The codebase is a mixed-up aggregagation of PHP, HTML, SQL, JS, and CSS, frequently all in the same file. And there are no tests at all! The “tests” are the QA team running over the site once or twice a week.

After that first day, when you felt so enthusiastic, you have been reduced to feeling like a brand-new beginner every day since. It’s humiliating. Each day has been a new frustration, a new “WTF?” moment replayed in a dozen different ways. You want very much to to improve the codebase as it is, so that you can impose some sense and reason onto it, but the code is such an overwhelming mess of spaghetti that you don’t even know where to start.

Overwhelmed and drowning in bad code that you inherited from others, you’re ready to give up.

Modernize Your Legacy Application

But what if I told you it didn’t have to be this way? What if I told you there was a specific series of small, incremental changes you could make over time to slowly make the codebase better, more modern, and thereby reduce your own sense that things are futile?

My upcoming book, “Modernizing Legacy Applications in PHP”, does exactly that. Using my talk “It Was Like That When I Got Here” as a starting point, I condense 15 years of fixing PHP codebases into a collection of specific steps to complete in order. As you apply these small fixes, each one building on the last, you will be able to restructure your codebase from a spaghetti mess to a testable, organized, modernized application, free of globals and mixed concerns.

Would you like to have that knowledge, distilled into an easy-to-understand book? Sign up on the mailing list below, and you’ll be the among the first to:

  • Find out how the book is going (and when it’s ready for purchase!)

  • Receive hints on how to improve your codebase now

  • Get a free pre-publication chapter

I promise, you’ll never receive any spam or other unwanted messages on this list. Add your email today!

Read the Reddit discussion about this post here.

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving you codebase, all while keeping it running the whole time.