We are due to meet on 10th March. Our discussions will be based around a book that we have covered previously. The list of our books is on LibraryThing, but remember we have already done some books twice. To vote, add a comment listing your three preferences in order.
[UPDATE: It looks like Agile Estimating and Planning is the winner in this contest, although Miquel made the election more complicated by not listing his preferences in order.]
For this meeting, I was joined by Tom, Miquel and Inigo, with the discussion based around Kent Beck’s Implementation Patterns.
Miquel began by saying that much of it was common sense. Tom agreed, but said that it was one of those books people say should be given to novice programmers. But then those beginners would probably miss out on the subtleties, so the actually time when it would be useful would be rather limited. Inigo thought much of it was too obvious, except for the handful of things he disagreed with, such as the variable state pattern and his views on final variables. On the other hand, he thought that there could have been more discussion about immutable objects and functional-style programming. It was generally agreed that they weren’t really ‘patterns’ as such – Inigo thought they were mostly ‘idioms’.
On the plus side, Inigo like the idea of the book and wanted to like it more. I agreed and liked the back-to-basics approach of saying “hold on why do we even split logic into methods?”. I also liked the slightly different way of thinking about the reader of your code. Kent Beck asks what the user will read ‘between the lines’ because of the implementation approach you have taken. Inigo liked the way he admitted his ignorance about such topics as concurrency and referred the reader to other books.
It was generally agreed that the book’s Java focus might be a surprise to someone picking the book up cold. I found the performance measurement section to be out-of-place. Inigo thought it would have been much more useful to have explicitly given details of hardware, operating system, JVM version etc. Miquel pointed out that speed is one thing, but maybe the memory footprint could be important for large collections too, but that is not mentioned.
I wasn’t sure that the use of the word ‘Symmetry’ was correct (see p15). To me, something can have parts of differing sizes but still be symmetric. I think the word ‘Uniformity’ would be better and in fact that very word is used by the author on p101 in relation to JUnit. Tom said that this concept was one of the few things he had taken from the book and he’d hoped for more. It seemed to him that some of the patterns were just dictionary definitions of the term, such as the ‘patterns’ around exceptions.
I think I was the only person to read the part about frameworks. I thought this was quite interesting though, as it discussed the differences between this sort of code and application code. In a nutshell, sometimes you might make a framework uglier on the inside to keep it clean on the outside and to limit difficulties when you make changes in the future. Kent Beck seems well qualified to talk on this, having been involved in the move from JUnit 3 to 4.