PHP Team Development book review

Book coverSo I’ve finally finished the book!  OK, I finished it a couple weeks ago but haven’t had a chance to post up a review yet.  Of course, I had every intention of finishing it a lot earlier considering I was flying for nine hours to the States and then another few hours on to Mexico – and the journey back again! – but that really was just wishful considering I was travelling with my two year old son.  Oh well! 🙂

On with the book review…

The book, as the title makes it plainly obvious, is about developing your team in relation to working with PHP.  It’s aimed at, well, pretty much anyone who has an interest in developing or working in a team, be it managers who need to set up and manage teams or developers working within a team who want to improve their work flow and procedures, or anyone in between.  It does this by giving an overview on several subjects, but doesn’t go as far as to tell you that you must do x, y or z.  This is understandable, though, as every team is different and the book acknowledges this.

Chapter 1 discusses the need for teams and the use of established software engineering patterns that can help as well as touching on some tools such as issue tracking, source control, etc.  This chapter is good if you’re not sure with a lot of terminology as the overview covers a few key topics such as continuous integration and regression, and also touches on software development principles.  It doesn’t go in to depth about any one thing, as they’re covered in further chapters.

Chapter 2 covers MVC (Model View Controller) design principles and how you might form you team to deal with different aspects of the MVC pattern.  To be honest, if you’ve dealt with MVC at all in your job then this chapter holds no surprises, as you will know how the pattern works and how you would give responsibilities to different team groups/members.  However, if you’ve not had any experience at all then it offers a nice little introduction to the pattern.  (Remember, though, that this is not about how you would code the MVC pattern or use it in your project – it’s about making the principles of the pattern known to you and how it may fit in to team working.)

Chapter 3 is about dealing with complexity.  That is to say, if you have a complex project or application then this chapter gives you an idea on how to manage that and implement things that will make your job easier.  Essentially, what this chapter comes down to is why it’s a good idea to use a framework.  Again, it’s nothing new if you’ve already used frameworks (generally by then you know all the reasons why it tends to be a good thing for complex projects), but if you’re contemplating using one, or sit in a more managerial role and want to know why your developers are using one, then it’s worth the read.  At the end of the chapter the author also gives links to a number of different frameworks – some of which I hadn’t heard of before – along with their license type and a brief description.  What I especially liked about this chapter is that the author came over quite framework agnostic.  He wasn’t saying that one framework is better than another or which you should use – he supplies a list of frameworks and arms you with knowledge of what to look for in a framework (commercial license, documentation, support, code quality, security, etc.) and sets you on your way.  It is, of course, up to you to choose a framework that best suits your project and then integrate that in to your team workings.  This is a Good Thing!

Chapter 4 is about the process to get from the concept of an application to the end product and the steps in between.  There are a number of flow charts throughout this chapter that help you understand the process, and for someone like me who generally goes from being told someone wants an application,  to getting a brief functional requirements set and then making the thing, I can see that I have room for improvement! 😉

Chapter 5 is about Agile development, and probably the chapter I was looking forward to the most.  Agile development was something I’d heard about, had an ever-so vague idea of what it was, but wasn’t too sure.  this chapter tells you what the principles are behind Agile development, how is works when dealing with the customer and a wide general overview.  The chapter then goes on to cover Extreme Programming (XP) a bit, and how Agile and XP can work in the team, pair programming, sustainable working styles for the developers, stand-up meetings, and so on.  It was good to find out a lot of how I work falls under Agile/XP, even though I didn’t know it at the time!  I learned a lot from this chapter and know a number of things I want to try to implement in to my working practice.

Chapter 6 is about collaboration among the team.  Basically it covers how source control is helpful, bug control and reporting, and ways developers can communicate (mailing lists, for example).  Useful stuff if you don’t know about it already, but pretty much any developer I know already uses source control in one form or another, as well as bug reporting, mailing lists, IRC, and everything else.

Chapter 7, the final chapter, is about continuous integration – what happens when your project needs to change, how does the project evolve, how to ensure team success and more.  Even though this is a distinct chapter in itself, I did get the feeling that it was more like a summary chapter of everything that you had just read.  But this was probably just because the author was referencing a number of his earlier chapters because they relatedto what he was taling about at the time.

Conclusion

This book is only 160 or so pages in size and it tries to cram a lot of information in to it.  There are times I wish the author could have gone in to more detail, but could also very much appreciate that the author didn’t have enough room to do so.  I actually quite liked that it was a really high-level overview for the most part, because it gave me a lot of ideas of things I want to investigate further and can now go and find resources that covers those bits in much more details.

Because I know quite a number of principles this book covered, such as the MVC chapters, source control, etc., I didn’t take quite so much away from it as another person may – and I’m sure other developers would feel the same – but I did still learn a lot from it, such as the agile development, and a number of keys principles that mayhelp me manage my time better as well as have a more integrated team.

However, this book wasn’t all roses and there were a number of things I really didn’t like.  The first thing is the authors style of writing.  I honestly didn’t gel with it very well and actually struggled to get past the first couple of chapters.  There was an overabundance of commas – sometimes breaking up the sentence in odd places – and it because a little repetitive and word for no reason.  My wife accuses me of using commas too much, which I probably do, but the amount in this book just caused me a headache!  The writing style I could get over (as mine’s not the best, but then, I’m not trying to sell you a book!), but the one thing that really pissed me off was that fact that the credits included a proof reader!!  WHAT?!  I lost count of the times ‘form’ was used when it should have been ‘from’, or the spelling mistakes, grammatical errors, or missing words entirely!  A couple of my favourites is when the author was discussing the use of functional programming vs. OOP, and then goes on to say, “Be it fictional programming you are using or object-oriented programming…”  Fictional programming!  And this highlights the commas quite nicely, “…we might be about to deal with estimates that are off the mark for some time, in the long run, both, the development team as well as clients and users will become frustrated…”  I don’t so much blame the author for these mistakes – I can’t imagine the pressure of writing a book and trying to get it spot on – but isn’t that why you employ proof readers and editors??

All in all I’d say that if you’ve been developing for a while and had any team experience then this book wont be of much use to you.  However, if you’ve never worked in a team environment, or don’t have much development experience, are a manager or something like that, then you may find this book quite beneficial to you for an overview of working in and establishing team working principles.

Did you like this? Share it:

Leave a Reply