php|architect's new clothes

As you may have noticed, php|architect has a new website to replace our five-year-old ball of code. This change has been almost eighteen months in the making, and one of the main reasons behind my general absenteeism from almost any form of non-necessary social activity during that period. If I haven't answered your e-mail, returned your phone call or otherwise ignored your existence, it wasn't on purpose—a man's brain only has so many CPU cycles.

Here, therefore, are a few observations on our new platform, its development and our strategy. Consider this the "how we did it" piece, with its "why we did it" companion to follow in a future post.

What's in a website?

I am constantly surprised by how many people don't seem to realize how complicated the technology behind php|architect really is. By the time we replaced it last week, our old system consisted of over 3,000,000 lines of PHP 4 code responsible for everything from backend management to distribution to online sales.

Even before it became that big, the entire application started showing signs of code rot—I have never made any secret of the fact that php|a grew, at least initially, without the benefit of any great strategic plan, and that was reflected in the way our code was written. Five years of functionality added only in response to immediate needs eventually creates all sorts of problems—the same functionality repeated over and over, monolithic pieces of code difficult to maintain and impossible to debug, and so on.

Eventually, the cost of adding new features—always a requirement of remaining competitive—becomes to be comparable with the benefits that these bring, and the business starts suffering.

Development Unstrategy

Arbi and I first started discussing a rebuild of the site back in 2005, when it was still much smaller and not quite the incredible bowl of code it would eventually become by the time it was replaced. The first difficulty we encountered was decided what the website was supposed to do—and, by extension, how the company itself was supposed to present itself. Were we a publisher? Or a training provider? Perhaps a conference organizer?

You can see that, eventually, we decided that we are a knowledge company—but, believe me, the road that led us to this decision was long and torturous. I will only say this: at some point, I had managed to convince myself that our homepage should work much like a web-based OS. I am glad the rest of the team fed me just enough rope to eventually hang myself and realize what a horrible idea that was.

As our work progressed, the site went through many different incarnations. Throughout, we kept what I like to think of as a "fluid set of specs" that changed as we were trying to assess exactly in which direction we wanted to take things. This may look like a poor way to build a piece of software—and it is certainly inefficient compared to having a solid strategy and running with it—but it did allow us the flexibility of experimenting and researching what the best way of doing things was for us without ever boxing ourselves into a bad decision we couldn't get out of. In other words, it took a while, but we eventually came up with something that reflects our needs: it provides us with a solid base on which we can build our future (sounds lame, perhaps, but it's true).

The Software Dilemma

I suffer from episodic "rejection periods" during which I become particularly hostile to a certain idea. For a while, for example, I couldn't stand working with databases; therefore, I became obsessed with the idea of storing and organizing data in the filesystem. At some point, I even became really fed up with PHP and decided that we should look at Python as our platform of choice for web development.

In the end, however, we did use databases, and we did use PHP 5. After all, it is a really solid platform, and most of our expertise lies with PHP anyway. Mucking around with other technologies, however, gave us some great ideas on how to implement certain functionality in the best possible way.

We started by developing our own framework. We stayed away from existing frameworks for a number of reasons—primarily that our needs are so unfortunately unique that we would have only been able to use a small portion of any other system anyway, and what good is a system that can do 100 things "well" when you only need four or five done "perfectly?" Similarly, I dislike the idea of loading up a million classes to perform one operation, and I find it an extremely odious way of developing software. Therefore, we established a single, simple rule: no more than three levels of inheritance. This may sound crazy, but it's helped us keep our code nice and shallow with no repetition whatsoever, resulting in high performance and a very simple execution model that can be easily debugged.

Next, we needed a frontend templating solution. Over the last few years, I have been particularly partial to XSL, and all of the new system uses XSLT exclusively for the frontend presentation layer (as well as some e-mail work). I cannot stress enough just how good this has turned out to be for us. XSL transformations are powerful but limited, thus forcing the developer to keep the frontend layer and the business logic (or the view and the controller if you live in MVC world) completely separate. PHP 5 has some incredible XML and XSL manipulation libraries, and the end result is a system where the frontend developer is free to much around as much as he wants without encroaching on the backend developer's turf—all the while using skills that are completely transferable, so that practically any frontend developer could step in and completely change the way our site looks without a single line of PHP code needing changes.

Finally, for our backend we went to a completely service-oriented architecture. No matter what you do on our site today, the actual functionality is provided by an underlying service that handles the real business logic—in fact, by hitting a single page you could be triggering a request to multiple services, all in different physical locations and therefore completely scalable. This was perhaps the most difficult choice we had to make, because we wanted to avoid the overhead of existing remote service systems like SOAP and therefore had to come up with our substitutes. 

Service orientation poses some unexpected challenges—like, for example, debugging—which take some time to solve. In the end, however, the payoff is terrific, particularly when you consider that a well-designed web service can be used by multiple frontend systems for multiple goals. For example, our backend management system is now based entirely on Adobe Flex, which has allowed us to combine the ease of Flash-based development with the convenience of a true GUI application and all the privileges that come with is—such as direct access to the network and nearly unrestricted control over the filesystem. Despite its power, the entire service management on the Flex side still takes less than one hundred lines of ActionScript code. I should here, publicly thank both Adobe and, in particular, Mike Potter for helping us take full advantage of their upcoming Flex 3 platform, which I think is the best thing to come along since sliced bread.

A new pair of shoes

The end result of all our hard work stands before you today—still a little rough around the edge, but already well-rounded and quite well tested by our faithful users, who kept us busy through the last week by pointing out bugs and suggesting changes to improve the overall user experience.

When I say "end result," of course, I use a term that is a bit misleading—the importance of the new system is in the fact that it represents a new platform on which we can build our future products, and that was the reason why we got into this messy business to start with.

* Image by chris27