techblog 

As I mentioned in my previous post, I was at XPDay 2006 in London last week. These are my notes from the second day.

Keynote: James Noble and Robert Biddle: Love in the age of software

I’m afraid that the notes I actually wrote during this are not fit to be repeated in their entirety. However I think that the phrase keynote panto sums up my thoughts. I’m not sure quite what point they were trying to get across, but unfortunately I found their presentation style intensely irritating. It involved some hit-and-miss (mostly miss) comedy, shouting, talking at the same time and feedback. I left about halfway through so I could be at the front of the queue for coffee. What was particularly ironic was the fact that some of their presentation seemed to be about communication. Surely rule number one of communication is don’t annoy the person you are communicating with?

Chris Matts: Managing Uncertainty and Risk using Real Options

This was the most interesting and useful session of the day for me. The speaker’s background is in proper financial options and so on. In this area, they use the Black-Scholes equation to determine the price of an option. However, he said that people who attempted to use this in areas outside financial mathematics were misguided, because it makes a number of assumptions that aren’t applicable outside that situation. This doesn’t mean that ‘real options‘ (which are just options in the sense of choices) are not valuable. He pointed out that often people would rather have a decision made, even if it is the wrong one, than leave things undecided. That’s just human nature. But of course, if you can delay your decision then you will have more information and therefore will be more likely to make the right choice. The important thing is working out when you actually need to make your decision.

He gave an example from ordinary life to show the value of these real options. He was flying back from holiday in Italy and due to arrive at Stansted Airport at 23:30 on Sunday night. He lives in Surbiton and works in central London. If he took a taxi home or decided to stay at an airport hotel, he’d have to book these in advance. He didn’t want to make this decision beforehand, so he took a suit into work, knowing that there was a shower there. In this way, he could stay anywhere for the night and still be able to get to the office on Monday morning ready for work. In the event he ended up staying at a friend’s house. But he was only able to do this because he didn’t have to make his decision until the plane actually landed. The cost of the option was low (just taking a suit in), but he saved himself booking an expensive taxi ride or hotel room.

A quote I liked, which came up in the questions at the end was:

Making a decision reduces the solution space, not the problem space.

Pascal van Cauwenberghe: The Toyota Way of Managing

This session was about the Toyota Production System and its philosophy. While it was good, I’ve heard much of this before in the context of Lean Software Development. This meant that I didn’t take many notes. I suggest you read my colleague Graeme’s detailed write-up.

Agile Adoption Experiences

This session was split into several mini-sessions given by a variety of different people from different organisations. I’m just going to summarize some of the interesting ideas that came out of these.

Manish Shah and Thomas Granier talked about doing agile away from the usual OO technologies that are agile’s usual area. They mentioned utPLSQL, which is a project I was once the maintainer for. There was a discussion of how to handle the problems of having multiple different customers who want different customizations to a core set of code. The solution put forward was to have a separate source control branch for each customer. This code was looked after by ‘pioneers’ who did the customization work. The core or ‘gold’ code was looked after by ‘guardians’ who made sure that anything integrated into the core did not disrupt the coherence of the system.

Dave Nicollette talked about how agile was introduced into two different companies. In one case (where he worked) it was bottom-up, the other top-down. Interestingly, in the first case the organisation was not in a very competitive market so management were not particularly interested in this area. However it sounded like a bureaucratic nightmare of an organisation, which is why the agile ideas started from the ’shop floor’. The second company was in a much more competitive arena meaning that the management were keen to find ways to make things more efficient.

What I liked from his story was when he described putting together his ‘agile dream team’ in the heart of this heavily process driven company. Somehow he got all the people he asked for, mainly because the people he wanted were those who questioned the bureaucratic processes. This meant that they were perceived as trouble makers which the managers were keen to get rid of.

Courage: How Brave are you?

This final session was a goldfish bowl style discussion facilitated by Giovanni Asproni. I’m not sure quite how much I got out of this, but the following are some interesting tidbits:

• The opposite of courage is paralysis.
• Courage is when you say to your team the thing that no-one wants to say. The elephant in the room, I guess.
• After a life and death situation, such as being lost on a mountain, fears of project failure just vanish, at least for a few weeks.

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…?

I wrote about installing a Araneus Alea I the other day. Since then I have been reading about how you test random number generators.

There is a discussion of this subject at Hotbits. This a web based random number generator that uses radioactive decay to generate the numbers. They have a program called ENT for testing binary data sequences.

Generating 1000000 random bytes with the Alea I can be done like this.

time ./randomfile -b 1000000 > /tmp/myrandom

real    1m21.073s
user    0m0.066s
sys     0m0.134s

Testing with the ENT program gives these results

./ent /tmp/myrandom
Entropy = 7.999817 bits per byte.

Optimum compression would reduce the size
of this 1000000 byte file by 0 percent.

Chi square distribution for 1000000 samples is 252.96, and randomly
would exceed this value 50.00 percent of the times.

Arithmetic mean value of data bytes is 127.5287 (127.5 = random).
Monte Carlo value for Pi is 3.144636579 (error 0.10 percent).
Serial correlation coefficient is 0.000713 (totally uncorrelated = 0.0).

According to the ENT manual this is very random data. Next I will be looking at what the NIST random number test tools have to say.