UKUUG home


(the UK's Unix & Open Systems User Group)






Book Discounts

Other Discounts

Mailing lists






Ship It! A Practical Guide to Successful Software Projects J Richardson and Will Gwaltney
Published by Pragmatic Bookshelf
200 pages
£ 20.95
Published: 10th June 2005
reviewed by Harry Newton
   in the September 2005 issue (pdf), (html)

This is a book about the other half of software development: the half that isn't writing code but which, if done badly, can cripple a project. For want of a better phrase, development process -- how developers should work to deliver good robust software. The kind of things established engineering disciplines do well, but software development does badly, and all too often atrociously. The subtitle of the book is ``A Practical Guide to Successful Software Projects'' and this gives a clue to the nature of the book. It is essentially a handbook of best practice as collected by the authors over their lengthy careers and varied roles. The real strength of the book is the pragmatic approach taken by the authors.

The book has four main chapters: ``Tools and Infrastructure'', ``Pragmatic Project Techniques'', ``Tracer Bullet Development'' and ``Common Problems and How To Fix Them''. The eight appendices are synopses of the tools available for the stages discussed in the first chapter, a list of development methodologies and recommended reading. The first chapter, ``Tools and Infrastructure'', is a straightforward recipe for building, testing and managing code. Topics covered include: sandbox development, automatic building, issue and feature tracking and test harnesses. The second chapter, ``Pragmatic Project Techniques'', is in a similar vein, but concerned with effective team working rather than each individual's working practice. It covers the role of the technical lead, the needs for effective team communication, code reviews and change notifications, and work tracking. The third chapter, ``Tracer Bullet Development'', is a discussion of the development methodology favoured by the authors. In this method, the project is divided into blocks of related functionality (e.g. client, database), interfaces established between them, and each block assigned to a different team. The smallest amount of code is written to glue everything together, the blocks being mock objects at this moment. The stubbed out blocks are then filled with functional code. The fourth chapter, ``Common Problems and How To Fix Them'', is exactly what it says it is. The problems discussed are mainly at a project level (e.g. ``We're on a `Death March' Project'', or ``Help! I've Inherited Legacy Code'') and, as with a lot of the book, the suggestions are common sense and practical.

All this may sound obvious, but it clearly is not. The authors quote a recent survey in which 40% of US software houses were found not to use any form of source control. Another survey shows that 70% of software houses have no daily build process, let alone a continuous integration system. The book is not dryly prescriptive. Although there are a series of recipes, its real benefit is in the experience of the authors. They are prepared to backup their suggestions with examples from their careers: they demonstrate and persuade rather than simply prescribe. This is what impressed me about the book. I didn't see it as reference, but more as a discussion that prompted me to consider the way I work.

Who should read it? Most people I think. It's aimed at technical leads certainly, but all developers would benefit by reading it. I believe that project managers would benefit from having high-level familiarity with the book's ideas. I thoroughly enjoyed the book: I found it a pleasure to read and was particularly impressed with the layout and organization of the material. Recommended.

Back to reviews list

Tel: 01763 273 475
Fax: 01763 273 255
Web: Webmaster
Queries: Ask Here
Join UKUUG Today!

UKUUG Secretariat
More information

Page last modified 02 Apr 2007
Copyright © 1995-2011 UKUUG Ltd.