This is a follow-up to my post Ship It! Sneak Peek, since Ship It! arrived not too long ago and I couldn’t wait to take the rest of it in.
The introduction gives a short overview about the rest of the books and gives some tips on how to read the book corresponding to your role, either developer, team lead or manager.
The rest of the book is divided into four chapters:
- Tools and Infrastructure
- Pragmatic Project Techniques
- Tracer Bullet Development
- Common Problems and How to Fix Them
The first chapter introduces common tools that should work for almost, if not any project. Continuous integration, issue/feature tracking, scripting your build, having a test harness, and the like. You do these things, right? I liked the good and short explanations of the kinds of tests you can write, since it’s easy for the beginner (it was for me) to confuse e.g. smoke tests with unit tests.
The second one explains common techniques for projects. The most important one for me is “Work From The List”. It’s a list containing all features and tasks for the project including an estimate and a priority. Everything you need to get going, and to keep your project running. The rest of the chapter goes into good detail about having a tech lead, communicating on a daily basis, code reviews and code change notifications.
All mentioned techniques might sound familiar to you, if you’re pragmatic as hell. But the book is not just a list of techniques, it’s a about how these techniques work, why they work and why they’ll work for your project. Although most of the stuff is used in my current project at work, I got a lot of new inspiration on what we could do better from the first 2 chapters. I recently had an epiphany when I finally saw The List in front of me on a whiteboard. It was one of these moments that you’ll never forget, because you see that it just works and why it works at the same time.
Every technique explained in these chapters is accompanied by a list of things you can do to introduce it in your project, and a list of signs of doing it right and doing it wrong.
The next chapter describes a development technique called “Tracer Bullet Development”, a quite interesting approach to developing software. First your team agrees on specific layers for your project. Each layer gets a skeleton that just returns fake data. When all layers are stubbed out and talk to each other, each team can start adding code to its specific layer. The pieces slowly come together as all layers come closer to being finished. Well, that’s the short version, but it’s a very interesting approach for new projects.
The book finishes with a collection of common problems and little recipes on how to fix them, including inheriting legacy code, a broken test suite, team problems, and the like. Very good stuff, always comes in handy to solve those problems every project experiences from time to time (or, always, if worse comes to worst).
I was amazed that these five chapters only take about 160 pages and yet tell you all you need to know about successful projects. I’ve experienced a lot of these problems myself, and so did/do you, I’m sure about that. Jared Richardson and William Gwaltney have put together an excellent guide for both developers and managers. A must-read, if you have problems in your team or projects, and a must-read to confirm you’re doing the right thing. As both the authors do I can only recommend to get this book, find a best practice that could improve the way you and your team work and start using it to see if it works for you. If you want to start small, check out the selected excerpts of Ship It!.