How could I avoid reading a book whose title is our favorite mantra at the office? Of course, it’s usually used tongue-in-cheek when that’s exactly what we can’t do…

Ship It! A Practical Guide to Successful Software Projects is a “pragmatic” book by Jared Richardson and William Gwaltney Jr. It is an easy read with lots of great ideas for improving your software development team.

The book starts by describing the infrastructure necessary to do successful software development. Hopefully every programmer out there is using source control by now, but there were some specific ideas that caught my eye; the book does an outstanding job of justifying them:

• Programmers should commit changes to source control at least every few days; if that’s not possible, they should commit changes to a private folder in the source control database.
• Creating a build machine should be as easy as getting files from source control and running a script. The build process should have no machine-level dependencies.
• The build script should run frequently, ideally whenever code is checked in, and should include automated tests to help prevent bug regression.
• Bug reports and feature requests must be tracked in an easy-to-use database.

The book then talks about techniques that help ensure success:

• The List is a prioritized list of measurable tasks that need to be completed. The team has a master list, and each programmer copies items from the team list to their individual list.
• Each item on the list should have a time estimate. When completed, each item is marked as finished, and the actual time is recorded. Time estimates will improve with practice.
• Each team needs a tech lead who maintains The List and monitors the direction of the team.
• The team should have a daily meeting where each person takes a minute or two to describe what they’re working on.
• No code should be committed to source control without a code review, generally by one other developer. Code reviews, like commits, should be frequent.
• The team should be able to easily monitor commits to source control.

The book also describes their process, called “Tracer Bullet Development.” I’m sure I’m missing something, but it doesn’t really seem much like a “process” to me; it basically describes a modular way of architecting a product and dividing the labor among the modules.

Finally, the book reinforces the advice it has given by presenting various common problems in the development process and the techniques that are important to solving those problems. Much of the advice in this section is on how to incorporate and maintain automated testing without too much pain.

I highly recommend this book to all software developers, particularly to those in leadership positions. I’m hoping that our development team will have the opportunity to try out some of these ideas and see improvement as well.