Jump to content

Check out our Community Blogs

- - - - -

Book Review: Ship It! A Practical Guid to Successful Software Projects

Posted by WingedPanther73, 20 April 2011 · 1184 views

Before I get too far, I'll say this: if you have already read a few books from the Pragmatic Bookshelf, you will not find a lot of new ideas in here. However, the book is short enough that it's a very easy read, and won't stress you out.

The focus on this book is simple, what can you do to get your product out the door? The material is broken down into four sections:
1) Tools you'll want in your company. This ranges from one-click builds to issue tracking to Continuous Integration with automated testing. These are the basic infrastructure type things that will determine what you CAN do.

2) Project Techniques. These are the methodologies you use. These range from having one person act as a buffer between the programmers (who need a lack of interuptions) and managers/customers (who need regular feedback), to having code reviews. The biggest item, however, is The List. This one item is first, and referred to constantly throughout the rest of the book. The idea is simple: have a prioritized list with time estimates. ALL priority 1 items must be in process before anyone can snag a priority 2 item. The list is flexible, and customers/managers/etc can add items to the list, but it's a great tool to let people see the impact of changes. It's also encouraged that you do this on both a personal and team level, and keep the list easy to see. I started using a personal wiki (http://hatta-wiki.org/) as my list, and have already pointed it out to my manager at my job.

3) Tracer Bullet Development is explained. This is a development methodology where you stub out all your method signatures first, but they don't do anything. For example, your code for ValidatePassword might look like this:
bool ValidatePassword(string username, password)
  return true;
The goal is to be able to COMPILE your project as soon as possible. You then build the actual code for the hardest parts first, and move on to the easy parts. Doing the hard parts first lets you adjust timelines early, and have only easy stuff as you approach the finish line.

4) Common Problems. Once all the preceding is in place, a list of common problems that software shops face is examined. This ranges from the rogue developer who likes to "refactor" code, breaking functionality in the process, to how to test "untestable" code. For about half of these items, having The List is a major component of addressing the issues. Solutions are explained from the perspective of a programmer, manager, or team leader, as appropriate.

There is one more section that makes this book stand out above the many others out there: the appendixes. Each appendix has URLs for various software packages that where available at the time of writing (2007). It will give you a great place to start on finding both free and commercial revision control systems, automated build systems, etc. Saying "get a revision control system" is easy. Saying "Here's five that work well" is something very different. The software landscape has changed, but it's still a great starting point.

It's a fun read, and it's practical... dare I say "pragmatic"? The best part is: I got good ideas from it.

  • 0

To me that Tracer Bullet Development (TBD) looks like Test Driven Development(TDD) ... without the tests :P
You start with a use-case / user-story / whatever you call it. Write the test (when no classes exist), using classNames and method names as you think you need it. Everything shows up red underlined, IDE complaining blabla.

Then you let your IDE generate all the classes and methods you wrote (IDE should be able to do this, usually creating a stub method like your validatePassword method). At this point you got the code that you would've had with that TBD. But with this TDD you had a use-case to begin from.

How are you going to figure out all the methods and classes you will need for the TBD? To me that looks like you're going to have a fairly deep analysis up front so you can gather up all the classes you will need with their methods.. But that starts smelling like waterfall development.

Edit: unless TBD also uses that list, and thus it's also item per item. It propably is. I kinda forgot about the list while reading your TBD bit, and assumed you'd write the classes and methods stubs / mocks for the whole project at once. :)
    • 0
It's very closely related to TDD. They also recommend that you use unit testing and continuous integration to help keep an eye on things. The main thing here is that many larger outfits cannot be responsible for funcitonality OTHER teams of programmers will be writing, so your idea wouldn't work quite as well.

They recommend having cross-team meetings to determine what the software interfaces will need to be. The authors are very much AGAINST waterfall development, btw.
    • 0
In my experience is project management of different thing whether its agile, TDD, Iterative or common sense. based on nature of project one gets important to other.
    • 0
Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download