Book Review: PHP Team Development

Generally, I only use this space to talk about concepts, products, and events that are important to me when I believe others can find value too.  I try not to write negative reviews because I don't believe it adds value to the community… but occasionally, I have to do otherwise.  In terms of disclosure, I wrote the publisher – Packt Publishing – and offered to quietly forget that I read this book.  Alas, they demanded a review anyway, so here it goes…

When I returned from CodeWorks in early October, my copy of PHP Team Development was waiting for me.  I was recovering from the trip, so I didn't get a chance to pick it up immediately and a number of other reviews were released.  When I considered writing my review, I tried to figure out what I could add that Lorna Jane, Brandon Savage, and Ken Guest haven't said already.  And then I came across a quote on page 66 that summed up the experience for me:

The philosophy behind ATK is to archive minimal code, eliminate code duplication, simplicity, and reuse.

While I don't know anything about the ATK project, I suspect they don't want to archive anything and they'd rather achieve some things.  Further, I don't think they want to eliminate simplicity or reuse.  Okay, okay, it's just a poor sentence structure and I'm being mean picking at one some little mistake.  Except that it's not one little mistake.  The book is filled with glaring mistakes like this.  If you're a regular reader of this blog, you know that I average 1-2 typos/post so maybe I don't have room to talk.

Of course, there is one difference: I don't have an editor.  I don't have someone with the sole duty of reviewing my writing and correcting it.  Packt Publishing does… well, at least I thought they did.

But if you ignore all of the glaring typos, odd sentence structures, and misuse of basic English, there are some other strong and weak points:

  • There is an in-depth discussion of MVC and how it can help your project.  While some of the discussion was good and applicable, the author seems to think that MVC is the Silver Bullet that will save every development team.  As Fred Brooks taught us in Mythical Man Month, There is No Silver Bullet.
  • Next, the author includes a section on Continuous Builds and Quality Assurance but there isn't a single mention of any of the tools to do this… phpUnit, CodeSniffer, phploc, phpcpd, phpUnderControl.  As Ken notes, since none of these tools are new, I'm trying to figure out why.  After all, we've implemented most of them in our web2project build script.
  • Next, it's odd to find new recommendations of CVS.  I understand that it's still used in numerous shops, but so is Classic ASP but I don't see anyone recommending it as a useful technology.
  • Next, I could be offended that he didn't mention web2project in his section about project management tools, but realistically, he didn't list any tracking or estimation tools.  Not even Excel.
  • Finally, for a book on PHP Team Development, there isn't much discussion of PHP or PHP-specific concepts.

Overall, I can't recommend this book to anyone. If someone on your team buys it, have them get their money back right now.  Lorna notes that a few chapters could be of value to new developers, but I have to disagree. New developers will just be more confused than informed by the end of the first chapter, let alone by the end of the book.

If you need a book along these lines, I whole-heartedly recommend Karl Fogel's “Producing Open Source Software”.  This book  – combined with some careful internal discussion and experience – has driven many of the process and practices within the web2project team.  I think it can be a positive and beneficial read for any Team Lead or Senior Developer.  And it's half the price of PHP Team Development.

Further, as of this book, I am no longer willing to receive or review books from Packt Publishing. My point of contact for this review was belligerent when I did not write a review within the first two weeks.  When I reminded him of my involvement with ZendCon, he responded with:

It is perfectly fine if you take a little longer to come up with your review considering your commitment towards the conference.

… thanks for permission?

Are you interested in API Design? Check out our new book "A Pragmatic Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available soon from LeanPub