I finished reading Ship It! yesterday, a book on effective software development. The book is an easy read, and like many of the books from the Pragmatic Bookshelf, it provides approachable and immediately-implementable advice. Personally, I love this approach: the book tells me where to look should I want to read more about the theory, but it focuses squarely on pragmatics.
I took several pages of notes while reading this book, mostly ideas to apply in my teaching and my mentoring of student projects, but some dealing with my own development. I have been using source code management software for about a decade, and I’ve been forcing my students to use it the last two years as well. However, I have no real experience with continuous integration. While I know enough not to break the build (and I advise my students likewise), I’ve never used a build server such as CruiseControl.
Similarly, I have used IDE build tools, and I’ve scaled up to ant for more complex builds (e.g. wrapping up multiple jars into one jar, signing it, and pushing it to a Web server with JNLP enabled), but I have never gone to the extent of automating the build outside of the IDE. Thinking back to last year’s Game Programming class, one of the problems we encountered was that about 1/4 the class was more comfortable in NetBeans than Eclipse. Thinking back on this and reflecting on the advice in Ship It, it would have made us more productive to factor out the build in an IDE-neutral way and let the students use what works for them. A potential complication here could be differences in the formatting of lines: I would hate to see huge repository changes just because someone did Ctrl-Shift-F in Eclipse — and I want them doing that for readability.
There is only brief mention in Ship It of Maven, and I’m not sure if that’s because it’s beyond the scope of their writing or if its a subtle way of reminding the reader to just start with ant and make decisions from there.
Two ideas strike me as recurring throughout the book. One is source code management: seriously, how does anybody live without this? I use it not only on my personal, single-developer projects, but also on all of my Documents folders. (Another with for text-based logical formatting over binary blobs, by the way.) The other theme is The List. Very simply, The List is a prioritized collection of all the things you need to do: features you need to implement, bugs you need to squash, risks to be mitigated, etc. It’s a very simple concept, but it’s good advice. After reading their introduction to The List, I decided to make a list of the things I need to do for work, so that I can start more rigorously estimating and prioritizing my time. Of course, the day I decided to do this was the day that I also had to coauthor an abstract. The good news is that the abstract was accepted; the bad news is that I still don’t have A List. More to the point, I wish the authors had given one or more examples of lists. I wonder if they have recommendations for specific ways to structure a list. For example, I started tinkering with putting one on Google Docs spreadsheet application, but its support for embedded text is not up to snuff (or I don’t know how to use it). Then I tried putting it into a simple document, but then I could not easily sort. It is circumstantial that I was looking into note-taking and list-making software for Android recently, and I didn’t find anything that matched the amorphous expectations that my brain seems to have.
The last section of the book provides a series of hypothetical problems along with suggestions for how to overcome them. I found this section to be the least valuable to me, since I am not actually a professional software developer. I find myself wishing that I had the kinds of problems that were described in this section, since it would imply that I have at least some semblance of reasonable conditions for software development. Ship It doesn’t deal with the kinds of problems I have as an academic, such as “I only see my developers for 75 minutes twice a week,” and “The promotion and tenure committee does not adequately recognize software development as scholarship.”
The appendices include links and brief descriptions of many pertinent software and process tools. I’m not sure how much lasting value such appendices have, since this information changes and can usually be found via Google, Wikipedia, etc. However, one appendix of particular value was a list of recommended readings, which included general reading on software development, recommendations for particular tools and environments, and even a section on leadership and skills. It’s funny that the authors of this book would recommend How to Win Friends and Influence People just days after one of my best friends recommended it to me; I suppose that means I should move it up the queue.
In summary, I enjoyed the book. A lot of the ideas within it should not be unfamiliar to software developers, but as one who is educating the next generation of software developers, it gives me a valuable list of topics to introduce into my courses. Highly recommended, even if you have to gloss over the last chapter as I did.