Bravely, many of us ignored Valentine’s day to discuss our latest choice of book, Ship it, which is another book from the Pragmatic Programmers. Six of us were in attendance this time, Tom, Chris, Graeme, Dave, Steven and Andrew.

We opened the discussion by talking about our initial reactions to the book. Chris liked the concept of considering the various techniques one uses to develop as habits. Steven felt it was his favourite book thus far. Dave was curious about the idea that they suggested where you could end up checking your IDE into your source control system. Graeme thought that this was a good framework to hang other methodologies off. We talked about methods for tracking issues and bugs. Dave recalled trying post-its for a day, and said that in his experience whiteboards could work to an extent, but it really was bug-tracking software that worked best for him. Steven added that he couldn’t check up on a whiteboard when he was out visiting clients for instance, but that a proper bug-tracking system was mobile as well in that sense. Using Trac also allows Steven and Dave to view the timeline of progress and check-ins, and that almost becomes a blog in itself. Chris saw that an actual blog is something he sees as being used (in how it is described in this book) as a means of external update for the customer, although Steven pointed out that he shares his bug-tracking with his customers.

We moved on to discuss the main development methodology described in the book. Chris pointed out that although they claim to be somewhat agnostic in terms of having a favourite methodology, on p107 they state “Being agile means you must adapt whatever isn’t working to better suit your particular needs”. They are Agile!

Steven had found Tracer Bullet Development as outlined in Chapter 4 “what I’ve always done, without ever knowing what it was called.” It didn’t appeal so much to Chris. Page 111: “A different development team works on each layer, and each team assumes that their layer exists on a different computer. This means that all communication between layers is over the network”. He felt that there are massive overheads in your code if you develop always assuming this. Tom and Steven disagreed that it was as explicit as that, and saw it as a conceptual idea to bear in mind during development. Graeme felt that if it was the case, it would mean you were covered should you wish to separate the layers out at a later stage.

Chris dug a bit deeper into it, feeling that it did mean for a lot of extra work, as you would need to serialise and de-serialise objects between layers. Tom pointed to the diagram of the layers model on page 121, and said that it looked to him a lot like the old Enterprise Java Beans layers model. Chris saw that it went against Martin Fowler‘s first law of distributing data objects: Don’t distribute your objects. He was also curious about how TBD allowed collaboration over the definition of interfaces. Steven pointed out that their approach to interfaces went against the shared ownership of code principle that Agile observed.

Dave saw this method as designing in a vacuum, his analogy being that it would be like drawing a character for a video game without having an idea of the environment it was going to be placed, the resolution and screen size. Tom didn’t like the idea of using Lego bricks to serve as objects when discussing the design, and bemoaned the lack of stories. He also agreed that the lack of crossover between areas seemed somewhat un-agile.

Chris noted that he did find the “do the hard bits first” idea appealing. Graeme pointed out it was like Agile/XP in some ways, but it certainly didn’t fit with what they would do in a first iteration of development, where they would both aim to provide working code, rather than simply pick the tough areas to develop.

There was then a discussion about how testing was dealt with in the book, and how members of the group found testing did and didn’t work. Steven found it quite inspiring how they showed so many different types of tests for different reasons. Tom pointed out that a lot of people seem to end up writing their own build systems, or altering existing ones substantially. It does seem to suggest that a lot of people are not happy with what is presently out there. Graeme noted that the book only offered 3 or 4 possible build systems, and Steven bemoaned that we were all lucky with Java, and that he had it far worse finding testing tools for dealing with C/C++ development. Chris and Tom pointed to Rake as something they had found very flexible for build systems, more so than Ant.

Steven thought that the methodology for code review in the book was wrong, the idea that you don’t check in until you’ve been reviewed. Graeme said that it prevented other people finding and solving issues in your code at an earlier stage, and Steven noted that they do make a slight reference to pair programming as being a possible solution for such issues, but that they don’t really push it. Dave thought that code reviewing to this extent was utter overkill.

We then briefly discussed stand-up meetings, and the project logs, before drifting into an extended discussion of where we learnt to code initially, and bemoaned the lack of opportunities for people to learn in the same manner as we did.

Take Home points from the evening:

Tom

• Lots of very similar practices and tools that I use, but there are also many contradictions.
• Their own experiences are interesting but they don’t always link them to well-known practices or methodologies.

Chris

• Hmmm, do you really need to worry about different layers on different machines?
• They don’t signpost where the ideas come from e.g. “This idea comes from Scrum”.

Steven

• Tracer Bullet Development – Layers on different machines seems over the top and complex.
• Define interfaces – why can’t a developer on one layer change other layers?
• Do risky/complex code first.
• Tests – Fish-eye tests?
• Rule – don’t stare at a problem for any more than thirty minutes before asking someone for help (a concept suggested by Chris).
• Testing – split into different kinds of tests for different occasions.

Graeme

• The basic diagram for their suggested infrastructure is very useful, basis of whole book, and a good methodology for development I suspect.
• Very good set of specific solutions at the end of the book for dealing with a wide array of issues that may arise from implementing their methodology, more practical than other approaches we have read about.