The past 5 years I have been lead engineer for a project and have seen it through several iterations of functionality improvements. Of course, with more users and with the curve of technology comes more requests for new pieces to be added to the original code base. However, the program has gotten to the point where simple changes are simply no longer simple. It’s difficult to explain to your bosses that a seemingly mundane task takes longer than it should. It’s even more difficult to try and have a small IT department be able to budget time (which we all know is money) to rewrite a whole code base.

Recently, I purchased Apress’s PHP Objects, Patterns, and Practice by Matt Zandstra Third Edition and on the first page in the very first chapter there’s a section titled The Problem. Obviously, I was intrigued. And then, more eloquently then I could ever think, much less present to my bosses, was a perfect description of what I have been dealing with for the past few years.

The problem is that PHP is just too easy. You write much of your code straight into your web pages, because PHP is designed to support that. You add utility functions (such as database access code) to files that can be included from page to page, and before you know it you have a working web application.

You are well onto your road to ruin. You don’t realize this, of course, because your site looks fantastic. It performs well, your clients are happy, and your users are spending money.

Trouble strikes when you go back to the code to begin a new phase. Now you have a larger team, some more users, a bigger budget. Yet without warning, things begin to go wrong. It’s as if your project has been poisoned.

A simple change, estimated at a day, takes three days when you discover that you must update 20 more web pages as a result.
Because of the application’s popularity, you need to shift the code to a new server. The projected has to be installed by hand, and you discover that file paths, database names, and passwords are hard coded into many source files.

Phew, I’m not crazy. “Many PHP projects start their life small and evolve into monsters” completely resonates with me. Don’t let this mislead you, the problem is not the language itself, but the way it is used. I was hired to work on this project and it began with the majority of the code in the database including the business logic paired with a PHP view rendering system and a couple of long files with procedural code to spit out the data. Finally, finally finally! I get to rewrite this program. Part of my bargaining was to work with a designer so while the engine is being replaced, it’s also getting a shiny new paint job.

The solution is not just to rewrite the program, but to write it correctly using objects, an appropriate pattern, and good practices. That is what the remaining 500 pages of the book describes.