Our office purchased a copy of php|architect’s Guide to Enterprise PHP Development (TOC) by Ivo Jansch last week, and I called dibs on the review. In it, Jansch sets out to identify tools and methodologies PHP developers can use (and have traditionally not used) to increase their chances of success. Jansch points out that PHP rapidly went from a tool used mainly to develop Personal Home Pages (I don’t know why I capitalized that… so weird) to an increasingly well-regarded enterprise-level platform. Unfortunately, while the open source community surrounding PHP is one of the most active and vibrant ones around, it has been reluctant to pick up some of the more formal development processes that the .NET and J2EE platforms are known for. We’ll dive deeper into the book in about 20 pixels. (You might have to click on a link or something, just a heads-up.)

This book attempts to fill that gap by walking us through the delightful and fruitful garden known as the software development lifecycle (SDLC). It provides a brief overview of each phase of development, ranging from pre-project team selection and hiring all the way through deployment and support. In each section, it outlines common pitfalls, ways to get around them and tools others use to keep things running smoothly.

Think of this book as an experienced developer watching your team in action through your whole process, and at the end, sitting you down and saying, “Look, you suck at this. You’re making every beginner-mistake in the book, so I’m going to break it down for you. This is the way you develop software, and here’s why.” This book is not about how to write code at an enterprise level (cf. Fowler, or Zandstra for a gentler intro), nor does it cover any one facet of the lifecycle in particular detail, rather it is aimed at getting you up-to-speed on the entire cycle and pointing you towards other resources to research further.

Following a couple of worthless chapters that we’ll mention towards the end of this review, the book is roughly broken up into chapters that follow each phase of the SDLC. This breadth is at-once the book’s strongest point and its weakest. Both Bob and I observed that certain chapters seemed rather weak, but it became clear to us that the subjects we were most familiar with were also the ones that the book seemed weakest on. It isn’t that these chapters are necessarily flawed, but rather that it is simply impossible to do any one phase justice in such a small amount of space (and the book is quite pithy, at a mere 175 275 pages. [author's note: apparently the php|architect website mistakenly lists the book as 175 pages. Shame on me for not verifying]) Nevertheless, there were so many gaping holes in our process (and must be in yours, as well, if you’re even considering this book still), that the payoff of those seemingly weaker chapters was the incredible wealth of introduction contained in one book. I’ll now outline a few of the chapters I found to be most useful, so that you can get an idea of what you’re in for.

The chapter covering planning was a gem for us. Software development is a notoriously over-time and over-budget undertaking and this book identifies a few reasons why. Reading this section, there were several “mmhmm” moments, where I was clearly able to identify instances where our team had made the exact mistake described. Jansch points out, for example, that software is never done. Give a developer 12 hours to complete a task, and he’ll complete it in 12. It could have been done in 8, but given the 4 extra hours, the developer took some time to create some better icons, add a bit of AJAX, and get everything just so. This tendency means that when we calculate the time required to do a task, adding a margin of time for safety, we are actually locking ourselves in to taking that full amount of time to complete the task. As a remedy, Jansch suggests that we instead quote a task according to the amount of time we think it should be done in. Then, a margin is added to the whole project, so that no individual task is simply allowed to go over. I have no idea if this actually works, but I suspect it addresses at least part of the problem.

The next chapter I was really impressed by was the chapter on tools. In this, Jansch identifies some tools developers can (and should!) use to streamline development and testing. The first subject this chapter addresses is the great IDE vs. Editor debate. Personally, I’ve been using IDEs to develop code from the beginning, but some developers need more convincing and Jansch makes a good argument. More interesting to me was the section on debugging. In the past, I did a lot of desktop application development, and one thing that I’ve always missed on the web-app side was the ability to do things like set watches and breakpoints in code. I was aware of Zend’s offerings in this arena, but had never looked into it any further than Zend Platform’s hefty price tag. As it turns out, there are numerous other offerings in this area.

The QA chapter was another that was useful to me. It discusses both functional and performance testing. We have been using unit testing here for a while, but performance testing was something that we’d only begun to need to consider with some of our more recent projects. In his section covering the topic, Jansch discusses the use of tools such as Apache Bench and Apache Flood, both of which allow you to run automated performance tests against your site. This kind of automation, as Jansch points out, is key in watching for serious performance problems, as well as regression introduced by new features.

One last tool mentioned in the QA chapter that I hadn’t heard of is Selenium (Tech Talk link). Selenium allows you to record and playback automated test cases that can check such things as whether the pages contains key elements (submit buttons, crucial bits of text), or whether the application is flowing correctly. This sounds very compelling to me (though I haven’t checked it out yet), as it addresses one of the key issues we’d been discussing with test-driven development around the office. Namely, unit tests are great for testing a specific very fine-grained aspect of the code, but how do you test the application as a whole? Anyway, that is the subject of a future blog post, no doubt.

Though this book is overall a strong read and a good buy for a team looking to streamline their processes and quit making the same mistakes over and over again, it does have its weaknesses. In this book at least, Jansch is at his best when talking about tools and process, rather than code. While object-oriented development is an important methodology in enterprise development, I don’t feel that the brief section covering the topic provides a very effective introduction. In my mind, Jansch spends a little bit too much time showing code and discussing implementation details (some specific to PHP), and not enough time discussing the advantages of OO on a conceptual level.

Similarly, the opening two chapters discussing the history of PHP, the LAMP stack, and PHP’s growing prominence in enterprise development were a bit too long for my tastes. The first chapter contained a lot of information that, while interesting, is readily available on the internet and hardly relevant to enterprise-level software development. The second chapter, on the other hand, felt like a combination of justification for the book, and sales pitch. Certainly I agree with Jansch’s stance on some of the weaknesses and strengths of PHP, but to my mind, a reader of this book is already aware enough of them to know he needs the book. I don’t necessarily feel that these sections should be removed altogether, but I did feel that in a book as short as this, they took up a bit more space than needed.

To be clear, these are minor shortcomings in an otherwise useful book. The great thing about a book like this is that it puts a lot of ideas into readers’ heads, which they can go on to research further. Just in the process of writing this post, I’ve linked to several projects that themselves would be worthy of their own post, and I even left out a couple of chapters that I liked. In short, I would recommend this book for any team looking for a broad reference they can use to enhance their development process.

Posted in: Reviews