Tag Cloud
My Reading List
This is a list of books currently on my To Read shelf... literally. I do not suggest or anti-suggest any of them at this time as I haven't read them yet.
- Agile Project Management with Scrum
- Beautiful Code
- Code Reading
- Databases in Depth
- Essential Business Process Modeling
- Good to Great
- Head First PMP
- Making Things Happen
- Manage It!
- Mind Hacks
- Practical Django Projects
- Prioritizing Web Usability
- Regular Expression Recipes
- Software Project Survival Guide
- The No Asshole Rule
Links of Interest
Current Efforts:
Blue Parabola, LLC
CaseyMultiMedia
web2Project
PHP'ers:
Ben Ramsey
Brandon Savage
Cal Evans
Eli White
Elizabeth Naramore
Joe LeBlanc
Matthew Turland
Matthew Weier O'Phinney
Planet PHP
Tony Bibbs
DC Social Media:
Aaron Brazell
Jessie X
Shashi B
Business/mISV:
Bob Walsh
Eric Sink
Gavin Bowman
Guy Kawasaki
Joel Spolsky
Micah Baldwin
Paul Graham
Planet mISV
Past Projects:
CodeSnipers
HOBY
Judicial Watch
mobile FoxNews.com
NRTW
Great Tools I use:
Drupal
phpUnit
Subversion
Zend Framework
User login
Search
Upcoming Events
Welcome
This is not the home of dotProject or web2project. It is the home of CaseySoftware, LLC. Any dotProject support questions should be referred to their support forums.
Recent blog posts
Items of Interest
- A Primer on Information Theory and Privacy | Electronic Frontier Foundation
- A Primer on Information Theory and Privacy | Electronic Frontier Foundation
- UNIX tips: Learn 10 good UNIX usage habits
- How do we kick our synchronous addiction? - Die in a Fire - Eric Florenzano’s Blog
- How do we kick our synchronous addiction? - Die in a Fire - Eric Florenzano’s Blog
Recent comments
- risk management module
1 week 4 days ago - web2project better than dotProject?
2 weeks 22 hours ago - Is this BETTER than dotProject then?
2 weeks 1 day ago - I have not gone through this
4 weeks 1 day ago - Pragmatic Programmer
4 weeks 4 days ago - Dash Board
4 weeks 4 days ago - Vacation hotspot, condominium rental service at Alabama & Arizon
4 weeks 4 days ago - hook_block
4 weeks 5 days ago - Dashboard
4 weeks 5 days ago - Agreed.
4 weeks 6 days ago
Popular content
Today's:
Ads
Date: 17 November, 2009 - 06:19
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?
Oh dear oh dear. This is
Oh dear oh dear. This is like an example of "how not to make a product", and I guess "how not to get your product reviewed" was a bonus.
Yeesh
Yeah, I had a lot of trouble with this book. I stand by my review, and that some developers might be helped, but the recommendations of CVS and lack of critical details made this book a poor read.
I think it's worth noting that there are entire books on most of the concepts presented in this one. I recommend people read the whole books, instead of the poorly written chapters in the this book.
speaking of recommendations
You'll learn a lot more listening to both The PHP Architect podcast ( http://phparch.com/ ) (buy the magazines too) and Software Engineer Radio ( http://www.se-radio.net/ ) than wasting money on that PHP Team Development book. I'd also recommend Matt Zandstra's "PHP: Objects, Patterns, and Practice" book.
Also, I still stand by my comment that spending €30 euro feeding ducks is more worthwhile than buying "PHP Team Development"!
Reviews...
It's really strange... this is the second product in these weeks that obviously requested reviews, while not being too good.
Do you have to request reviews if you made a good product?
Do you check your product before asking for reviews?
Don't you think that the actual request makes the reviewer maybe demanding critical?
I would maybe rather ask like "Could you feature our product if you like it?" to avoid all those bad voices if you're not sure about your product. (And even tell your peers that you're not too sure. )
Good Review
Good Job Casey! I started reading your reviews/blogs recently and started following you on Twitter. Thanks for being part of the community stronger! Good points on the book too :-)
Producing Open Source Software
The book you mentioned, Producing Open Source Software, is actually available online as well (although you should still purchase a copy and support the author).
Measurable Goals
I came to the conclusion that this person has an annual bonus hinging on him meeting his target of the number of reviews of books published on blogs!! I also replied to say that I had been distinctly underwhelmed and got a similar response. Keith you are a wise man refusing the books from Packt from now on - I always get hooked because the titles sound interesting and I'm an optimist!
Thank god...
...I declined an offer to write for Packt...
How many books from Packt Publishing have you read?
Hi Keith,
I am a Packt author. I don't find it fair that you base your conclusions on just one of the hundreds books published by this company. I have dealt with many Packt representatives at various levels and in my experience, the case you are describing is an exception.
Regards,
Marc Delisle
Packt Publishing
Marc,
While I've only read two - this atrocity and the dotProject book - you can see the public reaction that I've gotten... but I've also gotten numerous messages from others in the community along the same lines. Some of those people have been other Packt Publishing authors.
Further, If you read my review of the dotProject book, you see another set of problems. You see someone writing a book on a topic - and therefore claiming to be an expert - with zero participation in the community... and even worse, recommending practices which are detrimental and the exact opposite of established practices and recommendations...
Finally, many of Packt's "requests" are not phrased as requests and are often direct orders. Odd considering I've never had a contract with them in any way shape or form. I've just published one of the comments here. I have more which I've chosen not to publish.
Packt Publishing
Keith,
I'm not challenging your opinion on these two books - which I have not read, nor your experience with this representative.
However I would like to see what your reaction would be if the next two Packt books you read are good...
More on Packt Publishing
Marc,
I understand your point, but let me turn it around to you:
How many mediocre to terrible books should I read? How many times should I deal with their marketing people who command me to do things? How many other people in the community - including some of their authors - have to agree with me before I can stop giving them the benefit of the doubt?
I guess my point is: How many chances should I give them?
To be honest, I get great books from good to excellent authors and great publishing companies - you can read some of my other book reviews here - so why should I waste my time with these guys? Or recommend others to do the same?
If they're worth your time, that's your choice.
Thank you for your comments
Dear Keith
My name is Damian Carvill and I'm the marketing manager here at Packt. First of all, thank you for your honest review of the PHP Team Development book and I'm sorry to hear that you have had a bad experience with it and also with some of the communication from the team here at Packt.
I'm not here to make any excuses about the book and I appreciate that it has failed to reach the expectations that were placed on it and for that I apologise. I have had a meeting with Douglas Paterson, Packt's Open Source Publisher this morning and he is going to reply to you about some of the specific book related issues you’ve raised here.
Further to this, I'm disappointed to hear that you weren’t impressed with the communication from Packt employees and that is something that we're also working on. I would like to point out that the guys you’ve been in touch with work very hard for Packt to develop mutually beneficial relationships with key members of the community and on the whole, the feedback we receive is positive. English isn't the first language for many of these guys and as such, there are often issues with the translation, which can come across as being blunt or belligerent. This isn't intentional and I'm confident that they don't appreciate that this is how you might interpret their e-mails.
Again, I'm sorry that you have had a bad experience with our books and I would ask you not to judge the company on these experiences. We are committed to publishing a large number of books and the issues you are highlighting are isolated and don’t reflect the general quality of Packt books. I would be happy to send you further books with absolutely no pressure to comment or write reviews, just in an attempt to change your opinion.
Thanks again for your honesty; it's only through these up-front reviews and comments that we can learn how to improve our service and increase the quality of our books.
Damian
Feedback to Packt
Damien,
First of all, thanks for coming here and responding to the feedback publicly and civilly. You didn't have to do that and I appreciate it.
Next, I look forward to hearing from you and/or Douglas. I really don't want to deal with anyone else at Packt as I've expressed previously... and had to remind one of your guys of a number of times.
On the communications front in general, I have some concerns. As you note "there are often issues with the translation, which can come across as being blunt or belligerent", if it's a known problem, is it going to be addressed? When I asked my point of contact for clarification, I didn't receive any. And as a result of my review, I've heard from numerous other people along the same lines, so the problem may be more widespread than you realize.
In reference to the book itself, the lack of quality is simply shocking. I have been informed that you are looking to hire a fulltime proofreader. I wish you luck.
Sincerely,
keith
Thanks Keith for your
Thanks Keith for your response. I really don't want you to be in contact with lots of different people at Packt as it's unnecessary and I appreciate that you've already been messed about a lot. However Doug feels that it's important for him to address some of the issues you raise about the book, which is why he would like to add to this thread.
We are working very closely with our team who work with reviewers, websites etc. and run ongoing training courses to improve their communication skills and how they work with their contacts. We're committed to improving our standards and this incident will be used as a case study in how not to build rapport!
The person you've been in touch with about this review is new to Packt and is still learning. This is unfortunate and is a good learning point for him, which has been raised.
Thanks again and I do appreciate the time you've spent replying to me.
All the best
Damian
Keith, PHP Team review response
Keith,
I’m Douglas Paterson, Publisher for our Open Source books at Packt.
Having read your review of the PHP Team Development book, and looked at the other reviews mentioned linked within, it is clear that we have failed in our execution of the idea. The idea of the book was simple – to collect together information about the tools and methodologies that would be used by PHP developers working together on team projects. The important thing with a book like this is that it is specific – it does not want to talk about some kind of programming methodology unless it explains how to apply this to PHP programming. The book is not supposed to be a collection of general information, and it is left to the reader, to work out how to apply this to a PHP development project. This is where the value of the book lies – taking general information, putting it together for the PHP developer.
You have suggested an alternative book for people interested in this book – a book about running a successful free software project. I’m not going to dispute the usefulness of that book, but I will state that such a recommendation is exactly the opposite of what we were trying to achieve with our book. Our book was for PHP developers and its message should have been “we’ll make things easy for you – we’ll take all this information floating around about team development tools and methodologies, and give you a PHP-specific distillation”. Readers appreciate this – there are thousands of readers who appreciated this approach with our PHP AJAX book. Yes, you can learn about AJAX, and if you know PHP, then I’m sure you can put them together. However, giving PHP developers AJAX information in PHP-specific context is a better way of getting the information. If you want things in greater generality, there is no shortage of material floating around.
Returning to the reviews of the PHP Team Development book, I can see that people think we have a good idea, but they are not happy with the implementation of the idea. It’s not a good idea done half well, it’s a good idea done poorly, and this always excites a reviewer in a bad way. This is the fundamental mistake with this book - you've highlighted other problems with the quality of the book, but when a book fails with its central idea then this basically breaks the book. There were clearly process failures with this book which we will look into. We do not expect to wait until a book is published to discover these kind of things about a book.
You are not alone in your view of this particular book, and we clearly have a lot of tough questions to ask ourselves about this book. I’ve tried to give a bit more background to the kind of problem we were trying to solve with this book, and facing up to the fact we didn’t get it right. We've published a lot of books, a lot of good books. There is plenty for us to learn from this experience, and we will make sure that this shapes future projects.
Best wishes,
Douglas
PHP Team Review
Douglas,
Thanks for the response. A few quick thoughts:
* First, I think if you're trying to build an effective PHP development team, all of the principles hold true from building a general development team. My book recommendation - Karl Fogel's "Producing Open Source Software" - deals with many of the team managment, communication, and structure issues. And although the book uses the development of Subversion and its community as a case study, I think the principles hold true for any team... in the community or in a company.
* Futher, you state "The idea of the book was simple – to collect together information about the tools and methodologies that would be used by PHP developers working together on team projects."
I think the book was a complete failure on this front.
First of all, there was little in the book that was PHP-specific. Beyond the listing of the PHP frameworks, I can't think of anything specific off the top of my head. I'd check, but I threw the book in the garbage the day after writing my review.
Finally - and this is most important of all - there were no tools and few methodologies listed. The author talks about Agile, great. He mentions Unit Tests, where are the examples? (Does he mention phpUnit? I honestly don't remember.) He mentions Continuous Integration... and then discusses how people should integrate their code regularly. That's not Continuous Integration, so I don't know what to say.
Once again, I firmly believe that any developer picking up this book without a solid foundation in these topics will be more confused. And anyone with a solid foundation wiill just be annoyed.
Packt Reviews
Re the belligerent Packt contact pertinent to the review, personally I had the same experience after being approached to review two of their books. The contact acted like such an ass that I'll never review another book for them again.
I have not gone through this
I have not gone through this book yet. Good review though I can see loads of contradictory views in the comment section. I am planning to read this particular one because I am a php developer and always I am in the longrun of knowing something exceptional in my industry
Post new comment