Ship It!: A Practical Guide To Successful Software Projects

Front Cover
Pragmatic Bookshelf, 2005 - Computers - 198 pages
28 Reviews

Ship It! is a collection of tips that show the tools and techniques a successful project team has to use, and how to use them well. You'll get quick, easy-to-follow advice on modern practices: which to use, and when they should be applied. This book avoids current fashion trends and marketing hype; instead, readers find page after page of solid advice, all tried and tested in the real world.

Aimed at beginning to intermediate programmers, Ship It! will show you:

  • Which tools help, and which don't
  • How to keep a project moving
  • Approaches to scheduling that work
  • How to build developers as well as product
  • What's normal on a project, and what's not
  • How to manage managers, end-users and sponsors
  • Danger signs and how to fix them

Few of the ideas presented here are controversial or extreme; most experiencedprogrammers will agree that this stuff works. Yet 50 to 70 percent of allproject teams in the U.S. aren't able to use even these simple, well-acceptedpractices effectively. This book will help you get started.

Ship It! begins by introducing the common technicalinfrastructure that every project needs to get the job done. Readerscan choose from a variety of recommended technologies according totheir skills and budgets. The next sections outline the necessarysteps to get software out the door reliably, using well-accepted,easy-to-adopt, best-of-breed practices that really work.

Finally, and most importantly, Ship It! presents commonproblems that teams face, then offers real-world advice on how tosolve them.

From inside the book

What people are saying - Write a review

User ratings

5 stars
6
4 stars
11
3 stars
8
2 stars
2
1 star
1

User Review - Flag as inappropriate

"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.
 

Review: Ship It!

User Review  - John - Goodreads

This was a sort of text book for a tech training we did in house. There's lots of good tips and reminders in here, and the discussion of Trace Bullet Development offers some valuable insights. The ... Read full review

Contents

Tools and Infrastructure
13
Pragmatic Project Techniques
55
Tracer Bullet Development
105
Copyright

27 other sections not shown

Common terms and phrases

References to this book

Bibliographic information