Ship it! A Practical Guide to Successful Software Projects Book

"Ship It! A Practical Guide to Successful Software Projects" by Jared Richardson and William Gwaltney Jr. is a bit of mixed bag. There is good stuff in there, but the book tries to be too much and as a consequence it is at times too sketchy and incomplete. In addition the authors prescribe techiques that are not always appropriate.

The book covers three software engineering topics: tools, project techniques and a methodology. The chapter on tools and infrastructure is solid. They recommend that you implement developer sandboxes, software configuration management, scripted builds, continuous integration, issue and feature tracking systems and automated testing on your projects and I agree. In any project of more than a trivial duration where there are no huge technical barriers due to the products you are working with you should implement all of them.

The chapter on project techniques is less convincing. Some of the techniques are unproblematic. Having a short meeting every morning to make sure that everyone is on the same page and sending code change notifications for instance. Others seem to prescribe a way of working that might not be the best in your case.

For instance they have a simple scope management technique the call "The List", which is essentially just that, a list of all the work that needs to be completed. On small projects this probably works okay, but when projects get big you might be better off with a work breakdown structure and a schedule with dependencies all that.

Another example is their recommendation for frequent, short and informal code reviews. Collaborative development techniques such as code reviews is a good idea. Research has shown that this is the most cost effective way to increase software quality. However, research also shows that formal inspections are even more effective. In cases where high quality is important, it would probably be a better option.

The chapter also seems a bit incomplete. It seems like an embryonic agile method. Another reviewer noted that when the book was written methods such as Scrum were not yet established. In my opinion, you are probably better off with Scrum if you decide that agile is appropriate for your project.

Their project method on the other hand is interesting. Unfortunately the chapter describing it is a bit too sketchy for my taste. Also, it is more of a software integration strategy than a full-blown software engineeering methodology. They call the method "tracer bullet development", named after the bullets that allow you to see where you are firing your machine gun in the dark.

Essentially you start by dividing your system into layers, e.g. the GUI layer, the business logic layer and the data access layer. Then, you identify you system objects in each layer and the interaction between them. These objects and their interfaces are then implemented as stubs and integrated into a "working" system. Then you start filling in the blanks and elaborating the interfaces, keeping the system integrated all of the way. This strategy has several benefits. Having done the integration up front, you avoid the nerve-wracking tying together of components at the end of the implementation. The interface-orientation promotes cohesion and loose coupling, making the software more robust and scalable.

All in all, there is good stuff in there, but one has to wonder whether the book was the victim of time-boxed development and premature shipping.