techblog 

Earlier this week I was at XPDay 2006 in London. This was my third time at this conference, so how did I find it? It certainly seemed to be rather busy compared with previous years. The venue was Ironmongers Hall, which is an amazing old building surrounded by the brutal concrete of the Barbican. I’m sure there is some clever metaphor there, with agile software development being the human-scale alternative to the industrial-scale processes. It’s a great place, but I don’t think it could have taken more people without it becoming uncomfortable.

This was also the first time I have presented a poster at XPDay. I wanted to promote my book group and get some feedback from attendees, but I didn’t think it warranted an actual session, so this seemed like the perfect compromise. I was a little disappointed that the posters were situated at the back of one of the session rooms, rather than in a ‘public’ area. This meant that I had to promote it myself, so when I talked to people I suggested that they should take a look. But at least one person learnt about the group and might come along, so all that time fiddling around with Comic Life was not wasted…

Keynote: Joshua Kerievsky: The Selling Game

The first session was by Joshua Kerievsky. (You may notice I namecheck him in my poster - that is a complete coincidence, honestly). Apparently it had been suggested to him that he talk about scaling agile to large teams and organisations, because that’s what he has done. He decided to approach it from a slightly different angle and look at it as the ’selling’ of agile to people who may be skeptical or unsure. He talked about what people do in other areas when they are trying to sell something. He mentioned a problem he had with his plumbing, when 3 different plumbers gave 3 different diagnoses and quotes, ranging from $9000 down to $200. Not surprisingly he went with the final one, which involved blowing CO2 down the pipes to clear them rather than replacing all the pipes in the house (and it worked too). Referring back to selling agile, he said that he want to find the CO2 solution to scaling agile, particularly to avoid having to teach the same class to group after group of people in a large company. The approach he used was eLearning and screencasting.

Talking about selling again, he said that when you try to sell something, people will raise objections. He pointed out that these are not the same as rejection, but are more like uncertainty. The best tactic is to repeat their objection back to them, but then show them that their objection is due to lack of information or misconception. He talked about how he got external experts in metrics to provde measures proving the benefits of the agile approach.

The best point of the presentation was when he asked the audience how they would sell pair programming. They came up with a variety of very reasonable ideas. He then said that he doesn’t sell pair programming, he talks about the risks associated with solo programming instead. In fact, he usually gets the person he is talking to to come up with these risks.

Finally he talked about how if one group in an organisation uses agile successfully, others become jealous of their success and try to attack them. He likened these forces to organisational ‘antibodies’. He solution was to start selling to them early on too and also to carefully assess what approach will fit a particular organisation.

Ben Fuchs and Joseph Pelrine - Turning up the heat without getting burnt

This session was about conflict and difficult behaviour. Their thesis was that conflict can be a healthy thing within a team and that you need to keep things cooking to stop the team stagnating. Obviously this does not mean that you have fights breaking out! For example, they suggested that the conflict brought about by having players in a football team competing for a starting place was healthy for the team as a whole. They then gave various ways to push people just out of their comfort zone to keep things interesting. These ways to ‘turn up the heat’ included increasing work pressure, adding new people into the team, changing the physical environment or introducing new tools. I wasn’t entirely convinced by this idea, but it was certainly interesting.

The part that I found more interesting was about how to deal with difficult people. This was a series of questions, the most searching of which were “Why do I care?, has this violated some of my values?” and “Why is this behaviour occurring?”. I think that keeping these in mind might help to avoid just setting the bozo bit in these situations.

Joshua Kerievsky - Patterns of Refactoring

This session covered some techniques that he discovered while writing his book Refactoring to Patterns, which is about refactoring your code to (or just towards) design patterns. He found that there are different ways to do refactoring, some much better than others. Another thing he found was that there are some elegant refactorings that are not intuitive and that you often need more than just the standard “Extract method” refactoring and so on. The whole idea is that you make small changes and keep running your tests as you go. This is the fundamental Pattern of Refactoring which he calls “Piecemeal Refactoring”.

Unfortunately, often the situation is that you see the code is in state A and you know it would be much better in state B. It is difficult to see how to get from A to B in small steps. This means that you end up breaking everything in the hope that you’ll end up at point B once you’ve fixed everything up. I’ve been in this position myself. His various techniques and tricks help you make the transition and keep the test bar green. He had a special name for the red marks that appear all over the code when you follow the “sod it, I’ll just break it” technique: Refactoring Rash. I liked this colourful analogy.

One simple pattern he showed was ‘Narrowed Change’. In this pattern you isolate the piece of code that needs to change so that it can be changed without large scale breakage. Often this will be something like changing an Array to a List. In that case, you would encapsulate access to the object and then only once that was done would you change the type. Finally you would inline the getters and setters created to allow the change to occur. He compared this to putting up scaffolding around a building to do some work on it and then removing it at the end.

He showed a technique that he didn’t have a name for. In this situation you want to extract some functionality from one class and put it into another. First you create an empty class and just push something like a simple member into it, with the original class using a getter to obtain its value. You then extract a method in the original class and move it into the new one. I suggested “Embryonic Class” as it seemed like a mother and child, initially connected by a cord (that getter). He liked that, so perhaps it’ll show up in his next book…?