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 observation 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 UnstrategyArbi 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 DilemmaI 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 platfo
Popularity: unranked [?]