Review Addition: Practices of an Agile Programmer

Adding on to my earlier post about Practices of an Agile Developer. Here are more specifics on why this is such a great book.

One of the things I found so attractive about this book was its large section “Delivering What Users Want.”  I’m sure many of you have horror stories about management, leads, and developers who couldn’t have cared less about the customers/users.  Maybe you yourself think that customers and users don’t matter.  Here’s a secret for you: You as a developer most likely don’t pay yourself out of your own pocket.  It’s customers who buy your software which ends up putting money in the company’s coffers of which some ends up in your pockets.  It’s users who create a need for the stuff you’re working on, thereby enabling a flow of cash from said company coffers to said pockets.  Sorry, rant over.

The section on user focus hits some great points not which only specifically deal with enabling customer decisions to drive your products, but also forces you to think about why you should make various choices about how you’re building your software.  Desgin shouldn’t dictate, but guide.  Technology is cool, but can you really justify moving to that shiny new <Fill In The Blank> system?  Demos should happen often, and you should listen to what the audience tells you about the product.  I found this section to be very unique as compared to other books on Agile I’ve read.  There’s gold throughout the book, but this section in particular hit home for me.

The chapter on collaboration also brings up some nice points in a style different from other books I’ve read.  I particularly liked the bit on mentoring (but then I’ve written about that before…), and there’s a nice balancing article on letting folks figure things out themselves.  Feed a man a fish vs. teach a man to fish, and all that.

Again, as I mentioned in my other post, the Epilogue is just amazing.  Step-by-step guides on which practices to roll out first, plus two great guides for folks interested in trying to sell Agile.  One is written from a manager’s prospective on how to sell Agile to a team, the other from a developer’s viewpoint trying to sell Agile to management.  These are top-notch resources if you’re the lone voice trying to get pieces of Agile rolled into your envrionment.

All this may sound like I’m blathering on about the book.  I am.  It’s a great, great work right along the lines of amazing things like Peopleware.