Andy Palmer » Uncategorized

I’ll show you mine if you show me yours

andy — Sat, 14 Aug 2010 13:09:20 +0000

Bob Marshall posted on Twitter:

I want to get rid of the habitual naming of methods, like #agile #kanban #lean

I replied with:

@flowchainsensei sounds like a revolutionary idea. I’m in. now all we need is a name

and he replied:

@AndyPalmer I want … but seems sadly impractical or contrary to the way humans work

In 1956, George A. Miller wrote a paper arguing that the conscious mind, the part that contains our inner voice and that does the reasoning processes, can handle 7 ± 2 items at a time. My view is that, in order to be able to function within these constraints, we learn to group similar things together so that they take up less processing space.

For example, if I want to remember a six digit number, it might be easier for me to remember it as 3 two digit numbers than as 6 individual numbers. Very familiar numbers, such as the phone number of my parents only take up one space.

It’s like I’m carrying a fixed number of boxes, all of which are the same size, but in which I can store things that (in my own mind) are grouped together.

One thing I’ve noticed though, is that I begin to speak of the ideas inside in terms of the labels that I’ve added to the boxes. In terms of hard facts, like numbers or addresses, this doesn’t really make much difference, however, when the ideas and opinions in the boxes are much more subjective, this can lead to confusion and disagreements (or sometimes, vigourous agreement )

For example, imagine that I am moving house and packing my belongings into boxes. In one box, I pack the contents of the fridge and because the fridge is in the kitchen, I label the box “Kitchen Stuff”.

I say to the removals people, “The box labelled ‘Kitchen Stuff’ has to be moved quickly. It’s very important that this box is moved as fast as possible”.

The removals people reply “You’re insane. Boxes labelled ‘Kitchen Stuff’ have to be moved carefully, and that means that we have to take it slow”

“No,” I say, “this box has to be moved quickly. If you move it slowly the contents will be ruined”

“No,” they say, “if we move it quickly, the contents will break. We must move it slowly and carefully”

I open the box and show them the contents and they understand. “Oh, it’s fridge stuff. Why didn’t you say so? When you said ‘Kitchen Stuff’ we assumed that you meant plates and glasses”

When we put labels on things in the boxes, it becomes much quicker for us to talk in terms of the labels. However, although we may have boxes labelled in a similar way, that does not mean that the contents are the same.

The box in my mind labelled “Scrum” may match a great deal of the contents of the box that you have labelled “XP” or that someone else has labelled “Lean”. The good thing about these boxes in my mind is that I can have an object appear in more than one of them. I might even place these three boxes into another box labelled “Common sense” (although I strongly suspect that the box with that particular label is guaranteed to be vastly different between every person)

As with my conversation with the removals men, I can get into a heated discussion with someone if we’re talking in terms of the labels on our boxes.

“XP is this, this and this”.

“No, that’s Scrum!”

The only way we can truly reach an understanding is if we recognise that we’re arguing over a label, and open our boxes to compare contents.

Sometimes, I even forget what I have stored in my boxes. I might only be talking about my memory of the things that I think I stored in the box. Opening the box and reviewing the contents, especially when someone else is doing the same, can help me to find new ways of categorising the ideas within. We might even find a common ground and start a revolution.

So, next time we don’t see eye to eye about the memories of the contents of our boxes, remind me “I’ll show you mine, if you show me yours”

That’s just the way we do it here

andy — Wed, 17 Mar 2010 17:18:23 +0000

There is a story about a cage of monkeys. In the middle of the cage is a ladder and at the top of the ladder is a banana.
One of the monkeys climbs the ladder to get the banana, but as he reaches for it, the entire cage becomes electrified and all the monkeys get a sharp shock.
Another monkey climbs the ladder, with the same result.
After a few attempts, the monkeys learn that climbing the ladder means everyone gets a shock, and they don’t try it again.

After a few days, one of the monkeys is replaced with a new monkey. This new monkey sees the banana and moves towards the ladder. The other monkeys, not wanting to be shocked, leap on him and beat him up. The new monkey attempts to go for the banana a few more times, before learning that going for the ladder means that the other monkeys will beat him up.

Over time, each of the original monkeys are replaced with new monkeys. Each new monkey learns the lesson that going for the ladder means getting beaten. Eventually, there are no monkeys who ever experienced the shocks. The electric shock equipment is then switched off. Still, no monkey ever climbs the ladder, for fear of being beaten up.

Unfortunately, monkeys are unable to ask “Why do you beat me up when I go for the banana?”, but if they could, the other monkeys would probably say “That’s just the way we do it here”.

Sometimes, our processes are based on a situation that no longer exists (like the inactive shock equipment). Sometimes, people we ask “Why do we do it this way?” won’t be able to provide an answer. Sometimes, we’ll try doing something different and we’ll get the banana and sometimes we’ll get a shock. Either way, we learn something.

I’m going to do something different today. Are you?

The monkey story is not mine, I think I came across it in an NLP book. There are plenty of examples on the web

What do you keep in your Shu Box?

andy — Mon, 18 Jan 2010 12:20:04 +0000

Alistair Cockburn uses the term Shu-Ha-Ri regularly to explain different levels of learning.
The literal translation is approximately Learn/Follow(Shu), Detach(Ha), Transcend(Ri). A number of people I’ve discussed this with equate these levels to the Dreyfus model of skill acquisition. In fact, the Wikipedia article on Dreyfus links back to Shu-Ha-Ri.
In my opinion, this is doing an injustice to both models, and my slightly different interpretation follows.

Driving an example

Take, for example, learning to drive. As I learn to drive, I progress through the Dreyfus model, becoming a novice, then competent, then with a lot of practice, an expert. However, having only learned one way to drive, I would still consider myself to be in the Shu box.

Riding my way to the top

When I learn to ride a motorbike, I can take a number of similar practices from my car experience and apply them to the similar practices in the motorbike world, but I still need to be taught new practices (particularly around observation and hazard avoidance). After a suitable period of tuition, I am now competent in riding a motorbike. I would still consider myself to be a Shu level rider though.

Mixing it up

Now, while driving my car, I suddenly realise that the heightened observation and hazard avoidance techniques, essential while riding, are actually pretty useful while driving. I begin to blend the two skills together. I’m still doing it as taught, but I can pick the practices that are most useful from each and blend them to create something new. This is where I start to become Ha level, taking the most useful practices from a number of techniques and blending them to create something useful in a given context.

Taking it to new heights

Next, I learn to fly a plane, bringing with it new observational practices and new disciplines (e.g. pre-flight checks). Becoming competent here, I can blend some of the practices from flying back into my driving and riding and vice-versa.
Soon I begin to notice a strange feeling. I’m doing all the right things in my practices, but there’s something that seems not quite right, something that could be made better. After some thinking, I identify the missing piece of context and synthesise an appropriate set of techniques for that situation. I have gone beyond the known contexts and identified a new situation, picked or synthesised the appropriate practices for that situation and resolved it. This is Ri level. Having identified this new context, I can teach it to my Shu level students.

But mum, I don’t want to ride a bike

Each of the situations described above are very relevant to me, but that is not to say that you have to ride a bike to progress to Ha or Ri in a car.
Other practices and contexts can be learned on the race track, taking a 4×4 course, rally driving or on a skid pan. Indeed, the beauty of Ha and Ri is that I may bring skills from a completely unrelated area (First Person Shooter, Knitting) and use them to improve my driving techniques.

Softening it up a bit

So, how can we apply this to software? There are a number of practices, techniques and methodologies (e.g. Kanban, Scrum, XP, Lean, Real Options). By the definition explained above, becoming in all of these makes me a Shu level practitioner in each of them.
If I identify a practice from, say, Kanban, that is useful in a context in a Scrum environment, then blending two or more Shu practices takes me to Ha.
When I come across a situation or context where there is no guidance (all of my Shu boxes are empty), then I need to create a new practice or technique. I use my knowledge of similar techniques from a number of methodologies and come up with something that fits the situation.

In Shu-mmary (sorry, summary)

In my interpretation of Shu-Ha-Ri, we have:

Shu (Learn) – Practice driven. We learn the practices by rote and apply them without understanding of the context.
Shu practices are our tools, along with an instruction manual on how to use them in the situation they were created for. We can progress through Dreyfus model with each of our tools
Ha (Blend) – Context driven. Having learned a number of practices, and a number of contexts in which they are appropriate, we can pick or blend a number of different practices for any known context.
Ha practices are using our Shu tools in situations that weren’t described in their manuals
Ri (Transcend) – Dealing with unknown context / identifying new practices. Coming across a brand new situation, we are able to identify an appropriate way of handling the situation.
Ri practices are about creating new tools, either to handle a unique situation, or to handle an existing situation in a better way

I find that separating the Dreyfus model from the Shu-Ha-Ri model allows me to become an expert with each of my Shu tools without feeling that I should be able to apply them to unusual situations.
This is a useful way of thinking (to me at least). Rather than map Shu-Ha-Ri to the Dreyfus model, I choose to think of Shu-Ha-Ri as a skill in identifying contexts and tools.
You might want to discuss this with me some more in the comments

The Curious Case of the Missing Present

andy — Wed, 13 Jan 2010 11:34:10 +0000

Imagine, if you will, a Santa’s grotto in a magical department store. Fresh faced children, still glowing from the snowfall outside, line up to greet the jolly man.
Joy and laughter can be heard throughout the crowd. Parents breathe a sigh of relief that their children are behaving well.
The amazing thing about this particular grotto is that whatever you ask Santa for, you receive as you leave. That’s one of the wonderful things about magic.

The first boy runs up to Santa, jumps on his knee, looks into his big jolly eyes, and asks for a train set. As he jumps down to leave, the elves hand him a big box, and inside is a train set that is just perfect.

The next child, a young girl, runs up to Santa, jumps on his knee, looks up and asks in a sweet voice for an iPod. As she jumps down to leave, the elves hand her a small box, and inside is the latest and greatest iPod.

The next child, another young boy, walks slowly up to Santa, climbs onto his knee, looks up and says in a thoughtful voice “I’m really not sure what I want for Christmas”. Santa smiles at him, the boy gets down and the elves hand him a box.
As the boy returns to his parents, they look inside the box… it’s empty.
The parents go absolutely crazy and start yelling. “WHY DID OUR BOY RECEIVE NOTHING? WE PAID THE SAME AMOUNT AS EVERYONE ELSE HERE!”
The elves look shocked and say “Your boy did not know what he wanted, so we just gave him something that looked like a present but was actually nothing”
The parents reply “Surely there is a better solution than this! You could have sent him to the back of the line to think about what he wanted, or given him a gift voucher so that he could choose at his leisure later”
The elves answer, “Well, we could have done that, but this is easier, and it’s what all the other elves do. Maybe you should check to make sure that your boy knows what he wants and that he actually gets it in return”

I wonder if you will remember that poor disappointed boy next time you return null;

2009 Retrospective

andy — Mon, 11 Jan 2010 16:00:48 +0000

Last year, I chose 5 goals. How did I manage with these?

Write more (this includes blogging and code)

I definitely wrote more code this year, especially early on in the year when Antony and I started Pair With Us. I feel that my blogging is probably around the same amount as previous years. Ideally I’d like to set a target of at least one blog post a week.

Present at one or more conferences

I presented at (what feels like) hundreds of conferences this year

Antony and I co-presented at Agile 2009 (Chicago), CITCON (Paris), Agile Development Practices (Orlando) and the SkillsMatter BDD Exchange (London)

We co-presented our tutorial at Oxford University as part of their Agile Methods Masters course

I also presented a keynote session at the Software Tester Forum (Zurich)

Help out with the jNarrate open source project

As part of Pair With Us, Antony and I did a little bit of additional work on JNarrate, although the majority of our work was on Narrative Fixture, which is an extension of JNarrate that wires it into FitNesse.

Further my understanding around NLP

I read a lot of books around NLP and hypnosis in 2009. I also enrolled on a Hypnotherapy and NLP Practitioner diploma. I am still learning loads on this and I am really enjoying it

Have a look at learning LISP

Well, as Meatloaf once said, “Two out of three ain’t bad”. I didn’t have time to work through the SICP course. This will stay on the backlog as I am still quite interested to do this

What else happened?

2009 brought some changes outside of the list.

In March, Antony and I started Pair With Us, a series of unedited screencasts showing us working on the Narrative Fixture project, including all of the discussions, arguments, back tracking (and lots and lots of fun)

A number of people have shown an interest in the both our programming style, and our willingness to show all online, including a number of prominent software craftsmen, such as Uncle Bob Martin, Corey Haines and Jason Gorman
In July, I left ThoughtWorks to start up a new company, RiverGlide, with Antony Marcano. This has been very successful so far and I look forward to telling you more about the exciting developments (as well as some more of the history) in future posts

Pomodoro, AppleScript and Adium

andy — Thu, 02 Jul 2009 15:21:56 +0000

I downloaded this Pomodoro Timer from the Apple website.
It has support for AppleScript events, so I created a script that automatically sets my Adium status to away (with an auto-reply) while I am working on a Pomodoro and automatically sets it to Available when I have finished.

After much messing around, trying to work out just how the AppleScript pseudo-natural-language works, I ended up with this to set the away status:

-- This goes on one line in Pomodoro Setup -> AppleScript -> Start
tell application "Adium"
  to set the status of every account whose status type is available
  to the first status whose title is "Pomodoro In Progress"

and this to set it back to available:

-- This goes on one line in Pomodoro Setup -> AppleScript -> Reset and End
tell application "Adium"
  to set the status of every account whose status type is away
  to the first status whose title is "Available"

Tiny Types

andy — Thu, 02 Jul 2009 12:29:32 +0000

Mark Needham’s post on micro types sparked an idea in my head that recently came to fruition.
I was pondering on the Narrative Fixture code, and the fact that, although most of the internals are sensibly typed objects, at the FitNesse layer, we do a lot of passing of strings.
The idea (at least, my interpretation) with Tiny Types is that the string obviously means something, and that we can probably classify what that meaning is (we have a sensibly named variable for it, after all) , and so why not convert it to that meaningful thing as soon as possible.
This has the nice effect of making some vague things (such as typing on collections) much more explicit.

As an example, in the Casting Director we have:

Map> dressingRoom = new HashMap>();

and, after a little bit of refactoring, we end up with:

Map> dressingRoom = new HashMap>();

Personally, I’m a fan of low ceremony, high essence languages, but while working in a high ceremony environment, we can leverage that ceremony to provide us with a nice summary of our thinking, ready for the next time we return to the code.

Lazynchronous

andy — Wed, 03 Jun 2009 10:36:20 +0000

la⋅zyn⋅chro⋅nous /ˈleɪzɪŋkrənəs/

–adjective

having delegated a task with a desired output to a person or group of persons

Examples:

Asking your colleague / friend / network a question, where you could find the answer by using a popular search engine, would be a lazynchronous search.
Getting Mechanical Turk to transcribe your screencasts allows you to work lazynchronously.

Origins:
Compound, from virtue of laziness and asynchronous

Making Feedback More Effective

andy — Fri, 22 May 2009 12:12:24 +0000

Patrick Kua recently wrote a Guide for Receiving Feedback. He mentions that one way to understand how to receive feedback is to understand how to give it.

Here are some suggestions for giving feedback that will help to anchor desirable behaviours and enable change in less desirable behaviours.

Give feedback in the second person

One purpose of feedback is to keep desirable behaviours and to change less desirable behaviours in the person you are feeding back on. Who is the correct audience for this information? Is it the manager of that person?
Using the third person isolates you from the person, and can encourage the use of generalisations.

Consider:

Gina worked very hard on this project. She always seemed to be at her desk long after everyone else had gone home.

versus:

Gina, you are very dedicated. I remember, one Friday, I got home and realised that I had left my keys on my desk. When I came back to the office to get them, you were still there. It must have been half past eight.

Which feedback would have the most effect on you? Why?

Anchor desirable behaviours in the present

When you are giving feedback on desirable behaviours, use the present tense. Specific examples can be given in the past tense.
For example:

David gave a great presentation to the board. The audience loved it and gave him a round of applause

David gave a great presentation? Was it a fluke? Can he do it again?

Consider this alternative:

David is a great communicator. His presentation to the board captivated the audience for the entire hour, and received a spontaneous round of applause.

David is a great communicator. The fact that he is implies that he will continue to be a great communicator.

Address it to David:

David, you are a great communicator. The presentation you gave to the board was amazing, the audience was captivated. You really deserved that round of applause.

Which feedback would have the most effect on you? Why?

Anchor less desirable behaviours in the past, suggest alternative behaviours

Giving feedback about undesirable behaviours is difficult. We want to get the message across without appearing to be overly cruel or negative.

Geoff thinks that he’s the only one who knows what’s going on. He always tells people how to do their jobs

How does the person giving the feedback know what Geoff thinks? Does Geoff always tell people how to do their jobs? How do you think that Geoff will respond to this feedback?

Give specific, past examples of the behaviour, suggest a way forward:

Last week, Geoff asked me to do the monthly report, and then told me how to do it. I felt as though he was questioning my competence. If Geoff wants me to do the report, he only needs to ask me.

How will Geoff react to this one?

Address it to Geoff:

Geoff, last week you asked me to do the monthly report, and then you told me how to do it. This upset me, as it felt like you were questioning my competence. I’m happy to do the report, you only need to ask me.

Which feedback do you think would have the most effect on the way Geoff interacts with the person giving the feedback?

Feedback on this post is valued and encouraged

My current understanding of feedback was gained from my interactions with other great coaches, including Liz Keogh, Antony Marcano, Rachel Davies and more.
A special mention goes to Chris Pollard for really opening my eyes to the value of language and well-formedness when giving feedback to elicit change.

Showing FitNesse Test Results in Hudson

andy — Wed, 01 Apr 2009 14:01:47 +0000

Have you tried to get your FitNesse reports into Hudson?

Although it’s simple to get an Ant task to run the tests, and fail the build, it would be nice to see the results in Hudson’s junit report.
Unfortunately FitNesse outputs it’s results in a format that Hudson doesn’t understand. But that’s OK, because it’s all XML.

I knocked together a really quick Proof of Concept xsl and ant script that allow you to run the FitNesse tests and convert the output to the Ant junit format that Hudson understands.

It’s a work in progress, but it should be enough to get you going. Watch this space.
I ran it against one suite and Hudson picked up the tests (and failure) ok.

This is the build.xml that I found on Naresh Jain’s blog about integrating FitNesse with CruiseControl, with the convert target added

A slight update on the XSL. This one creates the correct nodes for exceptions and errors (although it appears to make no difference to Hudson)




  
    
      
    
    
      
    
    
      
    
    
      
    
    AcceptanceTests
  
    
      
        
      
      
        
      
      
        
          
            
              
               exceptions thrown
              
                 and 
                
                 assertions failed
              
            
          
        
        
          
            
              
               assertions failed