So, the date is fixed, we’ll be meeting on Thursday 30 July at the Lamb and Flag from 8pm to talk about testing and how testers fit into an agile project. The starting point for discussions will be Agile Testing by Lisa Crispin and Janet Gregory. As usual, it is not necessary to read the book, although a passing knowledge of the subject might help!
You may have noticed that the group has been rather quiet for the last few months. I was hoping that someone else would volunteer to run it. But no-one did. So I sulked.
But now I have a book sitting on my desk that I’d like to read, but I need a push to get started. So maybe we could wake the group from its sleep to cover this? It is Agile Testing by Lisa Crispin and Janet Gregory. Ideally I’d like to discuss this in the first week of August. Anyone else interested? UPDATE: Let’s pencil in Thursday 30 July!
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.
We’ll be discussing the topics in Kent Beck’s Implementation Patterns at the Lamb and Flag from 8pm on 10 February 2009.
Our meeting on Tuesday 13 January will be a new year social event, since not much reading has taken place over the Christmas break. As usual, it’ll be at the Lamb and Flag from 8pm.
Just me, Steven and David turned up for this one. We were looking again at Michael Feathers’ book Dealing Effectively with Legacy Code.
Steven began by saying that he still thought it was a good book, with a poor title. This was the general consensus last time we discussed it. I’ve certainly picked up some techniques from it, in particular the idea of subclassing the class under test to stub out external dependencies. Steven said that originally he’d thought that there might be some overlap with Martin Fowler’s Refactoring, but having thought about it he decided that there wasn’t. Everywhere where this might happen, Michael Feathers references Martin Fowler. I suggested that this book was probably one of the most under-appreciated books in the area of refactoring and design.
A technique which I found interesting this time was “Scratch refactoring” which is refactoring just to learn about the code. Steven agreed but was slightly concerned that there would be a temptation to keep the refactored code rather than throw it away. (Remember, you have no tests for this…)
Another interesting technique was “Characterization Testing”, which is creating tests simply to document what some code does currently. This can then be used to allow refactoring to take place. These tests can subsequently be thrown away and replaced by proper unit tests once the code is in better shape. I suppose the danger is once again that this scaffolding will not get discarded.
Steven mentioned that the chapter on testing code that is all API calls was particularly relevant. He has this exact situation and had always thought that this code was not testable. Having read the book he may get it under test.
David (arriving a little late) said that he thought it was a brilliant book. The only problem is that he would prefer a small number of files to look at whereas with Java you tend to get something of an explosion of classes. Using dependency injection tends to exacerbate this. We moved on to discussing dependencies between packages and I gave Structure 101 a name check. I’ve used this at work to keep dependencies in check - a fact which I have blogged about.
We moved on to the idea of “Architecture as a story” which Michael Feathers discusses in Chapter 17. The idea is that if you can encapsulate the architecture as a story it makes it more likely that it will survive over time. Something like having an oral tradition in place of a document.
Finally, Steven said that he thought that this book was one he would aim to keep close by in future. So when he needed to get code under test he would be able to refer to it for help.
It is time to choose the next topic to discuss. So choose 3 books with some kind of agile angle and vote for them in order in the comments below. EDITED January’s meeting will be a new year social get together and we will discuss the topics in Kent Beck’s Implementation Patterns in February.
We will be meeting from 8pm on 9 December at the Lamb and Flag to discuss Legacy Code and Testing. The starting point for discussions will be the book Working Effectively with Legacy Code. Come along if you are just interested in the subject and have not read the book, or if you have war stories about taming a legacy system.
It was a bit of quiet meeting - just me and Tom turned out for this one. This discussions were around the book Fearless Change by Mary Lynn Manns and Linda Rising.
Tom began by saying that he was a little impatient reading the book. He wasn’t sure if this was because the book wasn’t getting to the point quickly enough, or if he was just short of time to read it. I pointed out that there is an Appendix that sums up the patterns and shows where they fit together. I think it would have been even better if there had been a map to show the connections between the patterns and the order in which they are applied.
I mentioned some of the patterns I found to be most interesting. In particular, Ask for Help, Group Identity, Piggyback and Just Do It. Once you read them, they seem obvious, but perhaps when you actually need to apply them it might not be so clear.
Ask for Help is just that and is a call to go against the grain and actually seek out others to help your cause rather than assuming that you need to do it all personally.
Group Identity is about forming a team or a movement around a name. I mentioned IBM’s Black Team, which I believe is mentioned in Peopleware. I’m not sure what Tom made of this, especially the idea that they would start wearing black to form an identity. But it seems like they were effective.
Piggyback is where you use pre-existing meetings and other structures to help move your idea forward. There was a story about starting a fringe conference just after another one to improve the chances of it getting attendees.
Finally, Just Do It is a call to get on and make changes. This seems to fit in with the maxim that it is “Easier to ask forgiveness than permission”.
Tom wondered if the book needed to be quite so big. I thought that a few patterns seemed to be very similar, such as Corridor Politics and Whisper in the General’s Ear. Both of these are about influencing key decision-makers in an informal situation. I might have preferred it if the initial twelve chapters which introduce the patterns in their settings had been supplemented by brief descriptions of the patterns. I’m not sure that having an alphabetic list is that helpful.
It sounds from the above that I didn’t like the book. But I did. For more, take a look at the interview with Linda Rising at InfoQ.
Finally, Tom had a flash of inspiration that this book fits into a tradition of management patterns books started by Machaevelli and The Art of War. I think that was the most profound comment of the evening.