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
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."