Ship It!, from the Pragmatic Programmers series of books

Book review • Those new to the Pragmatic Programmers and who are serious about their craft would do very well to read the book that started the series, The Pragmatic Programmer: From Journeyman to Master, by Hunt and Thomas. In a world full of cutting-edge technologies and books that are out of date as soon as they go to print, it is a book about the craft of software development, and how to become a master in it. Those experienced in software development know that moving between major technologies is easy for those who grok “software” as opposed to just Java or .NET - the words may be different, but the principles are the same and the practices vary only a small amount, and it’s a book that teaches you how to use your tools and your skills like a professional.

But I digress, because this review is for Ship it!: A Practical Guide to Successful Software Projects, a guide to getting software projects done and out of the door, from the publishing house started by the two pragmatic programmers. This book is firmly aimed at the engineers doing the development work - there’s little talk of requirements and scheduling, or other project management issues. This is all about using the right techniques to get your code working reliably, and your coders working together. Richardson and Gwaltney have experienced working on - and in some cases rescuing - many projects, and this book documents the practices they have found works best in their experience for getting software finished.

The first section of the book (after the Introduction) is Tools and Infrastructure. Projects stuck in a rut of dysfunctional source code management and frequently-breaking code will find the essential, minimum techniques spelled out at the beginning of this section - basically, use source control to manage all code and assets, and work from your own private working copy instead of a network share. Moving on, there is sensible advice on having a build script to build your project in one go, and then automating this with a continuous integration system. Keep a defect tracking system, and use testing.

Anyone who has been following software engineering, especially agile methods, will be familiar with all of these techniques, although I’ve no doubt that the level its practiced is much lower. This chapter serves as a checklist for what every software project should be doing. Each individual step isn’t huge, but all used together it does give you a lot more confidence that your software is building correctly, nobody’s changes are being lost, and that the project is coming under control.

The next chapter, Pragmatic Project Techniques, is focussed mostly on people instead of tools. It starts with the technique that everyone uses to manage their work - keep a list, keep it prioritised and always work on the highest priority items first. Again, basic stuff that most people will know, but that not all will practice. It introduces stand-up meetings and code reviews.

The next chapter introduces a development methodology, Tracer Bullet Development. The authors note half-jokingly that a book like this ought to propose a methodology so they felt they should include one. I felt this was a weak part of the book and didn’t really learn too much. “Tracer bullet” was a technique that Hunt and Thomas wrote about in their first book, and while it is a useful technique, it is a bit of a stretch to turn it into a full methodology. It’s a worthwhile read, but not a technique I expect to deploy in full.

Next is Common Problems and How to Fix Them. Exactly as it sounds, this is a list of ten or twenty problems, a mixture of technical ones such as “testing untestable code” and “it hurts when I integrate the code”, to people-oriented problems such as “you’ve got a rogue developer” and “your manager is unhappy.” It’s full of practical advice delivered in a calm, don’t-panic style.

Finally there is a summary of the tips offered in the book, and then references to tools to fulfill tasks in the earlier section of the books, such as source control and continuous integration. This is useful, but is also likely to be the part that falls out of date the quickest. It would have been useful for the website to keep an up-to-date list of tools, but this opportunity was missed.

In my view, the first two sections are the most useful, and I would have little hesitation in applying all of these techniques to projects I work on. They are proven techniques for getting a project under control, keeping defects and features tracked and keeping everybody’s confidence in the project high. The tracer bullet methodology I doubt I would deploy in full, but I would certainly take elements of it into my projects.

As I have said, for many people this book’s advice will not be new. Techniques such as continuous integration and stand-up meetings have been part of the agile methods movement for several years now, and any software developer who is not using source control is making a serious mistake. However, getting buy-in from other team members and management for some of the more radical techniques can be difficult, and it is reassuring to know that the authors own experiences have proven that these techniques work.

In conclusion, I would definitely recommend this book for this checklist in the first couple of chapters - read it, get your team to read it, and come back to it regularly to make sure your practices haven’t slipped. The rest of the book I am not convinced is the best practice you could follow, but still makes an interested read to influence your own processes. Finally, as I mentioned at the start, this book is firmly aimed at the coding part of the project process - on its own, it’s not a complete guide to shipping software, but would complement a more general software project management book very well.

Ship it!: A Practical Guide to Successful Software Projects
by Jared Richardson and William Gwaltney
Paperback, 200 pages
Publisher: Pragmatic Bookshelf (1 Jun 2005)
ISBN-10: 0974514047
ISBN-13: 978-0974514048