Ship It!: A Practical Guide to Successful Software Projects
by
tonyC
—
last modified
2006-11-05 02:25
review by Shriram Natarajan, October 2005
![]() |
| The authors show their game plan of the book in a pictorial road map in the introduction. The text of the book fleshes out the different parts of this world view. The major ideas conveyed by the book can be refreshed just by looking at this roadmap/world view. |
| The ideal reader would be some one who is hurting a lot and wants to rapidly improve their situation. This book has instant recipes to start working towards a healthy process and equipping the reader with the ability to pick correct processes. For a person that has most of the tips/processes implemented, this book serves as a validation for current work practises, holds pointers for improvement, and a checklist of symptoms to watch out for. The ideas are presented in an open minded manner: the authors do not want to force their ideas; instead they rely on showing how it worked for them and their projects. Side notes are for folks "really high up" that want a business summary of the text. The side notes serve as an anchor for these folks to zero in on |
| "Ship It!" is an easy read. There is
copious amounts of white space and margin space for notes. The ideas
are coherently presented. The various side bars and footnotes explain
some facets of the discussion in greater detail. The tips are
highlighted and put in separate boxes. The tips are collated at the end
of the book too. Some tips are worded too generally -- one has to go
back to the text surrounding the tip to find out what the tip was
talking about. The tip summary could have included the chapter under
which the tip was given - that would have been enough for understanding
the context. Some of the screenshots and pictures are redundant for
folks in the trenches. |
| A significant portion of the book is
taken by "known issues" and appendices. There is a good amount of
overlap between the problems faced and the tips presented in the
preceding sections. Probably it was meant as two views on the same
ideas. One view is constructive (i.e.this is how you do stuff), the
other view is keyed on problems (i.e. if you have this problem, you
should try this). |
| Contents: The ideas presented in the book are all known truths about agile development. This book does not have high original content -- it collates the various practises that are espoused and shows why it is needed to fit the agile processes. The TBD (tracer bullet development) process is the new aspect presented here. |
| This book is guaranteed to generate
discussion and healthy debate, especially among people/organisations
that strongly believe in the status quo. The best way to read it is to
keep a track of what the book says and what your organisation is doing.
If you deviate from the recommendations, one tends to find the reason
for it. This can be a light weight process check/audit. Even if only
one person in the organisation is using it, it can serve as a testing
ground for current practises. |
It is pragmatic:
|
It is fractal:
|
| The Table of Contents can be found at the Pragmatic Programmer's website. |
