For the past week, since I returned from OSCON, I’ve been
reading the last book in the Pragmatic
Starter Kit
series. I’m not quite finished with it yet, but I
thought I’d post my thoughts so far. This book finishes off the
definitive guide for a team that wants to do software development
right.

The first two books, Pragmatic
Version Control
and Pragmatic
Unit Testing
, lay the foundation for repeatable, reproducible, and
(surprise surprise) automatable software development processes. Mike Clark’s Pragmatic
Project Automation
puts it all together in a how-to guide that should
serve as a blueprint for any self-respecting team.

The Starter Kit takes what’s inarguably right about the Agile approach to programming and
strips out all of the confrontational, sometimes scary,
methodology-specific stuff, leaving readers with a step by step list of
practices that can and should be applied to any project. The books’
examples focus on the use of free tools, mostly
in Java, but the practices laid out transcend language and environment and
can be applied to nearly any software development environment.

I especially enjoyed the step-by-step guide on setting up CruiseControl, as
it’s been a bit finicky for me in the past. And, I love some of the
creative ways that Mike lays out to stay in touch with your automated
processes (RSS, SMS, lava lamps ;).

In general, if you’re an experienced and conscientious software
developer, you’re probably not going to find a lot of surprising
advice in the Start Kit. What’s unique is the fact that it’s
all pulled together into one cohesive package and laid out in such a way
that it’s a no brainer to follow (not to mention entertaining to
read).

If you’re a software developer or (especially) a manager of software
developers, you should plan to buy every book in this series. If
you’re using Java on your projects, you should go
buy them
right now. I’ve been pushing a lot of these ideas for
years with geographically distributed teams, and now that this series
exists, it (with The Pragmatic
Programmer
and Martin Fowler’s Refactoring) will
be the first thing I give to a new team member.

"This is the way we’re going to do it."