The whole event felt very professional and well-run. Many of the speakers were people who I recognised or knew from the Ruby community, and I was excited to see what they had to say. The talks varied from heavily technical to very non-technical, and each speaker was well-prepared and delivered their talk in an engaging way. We also had a first-rate MC in the guise of Dr. Nic Williams. The promotional video was brilliant, and the space theme ran on into the conference, with a really theatrical beginning to the conference: the sounds of a rocket-launch, dry ice and Dr. Nic coming on-stage in a full space suit.

As a speaker, I was treated incredibly well. The Codegram staff were just lovely, and checked with me several times a day whether I was OK, if I needed anything. We had our own private room where we could go to chill out away from the crowds. I had free drinks all night long at the parties.

So what am I complaining about?

Well, let me get this straight first. I’m not complaining about Baruco itself. I can’t imagine a nicer bunch of people than the Codegram team, doing a better job of a conference in this single-track, speaker-to-audience format. It’s the format that leaves me uncomfortable.

This format, where big names deliver polished talks to a large audience, seems to be incredibly popular in the Ruby community, yet means that most of the people who attend hardly participate at all. Yes, there are Q&A after the talks and yes, there is usually a slot for lightning talks, but it’s often put towards the bottom of the bill, or sidelined into an evening slot. Mostly, you just turn up and consume ideas from the people on the stage.

This, to me, defeats the primary purpose of a conference. If we just turn up and listen, when do we get a chance to think for ourselves? How do we make new friends when we’re spending so much time in a darkened theatre?

I think that a straight speaker-audience format conference promotes a hero or rock-star culture within the Ruby community, and I think that rock-star culture is poisonous.

I’d like to see our Ruby conferences be much more level playing fields, where we really feel like a community coming together.

Some specific things I’d like to see a lot more of from our conference organisers:

Mix up the session format

Instead of just talks, let’s have a mix of talks and hands-on sessions. Hands-on sessions give you a chance to experience a new idea instead of just hearing about it. Plus you get to make friends with the people sitting next to you by doing something you both have in common: playing with Ruby.

Make more space for unplanned sessions

I’ve been to lots of open-spaces (sometimes called unconferences) and even run a couple myself. What I think is so wonderful about this format is that you can come up with conference content during the conference so if you’re inspired to hack on or discuss something, you can find some like minds to join up with.

I think you need planned, scheduled talks to give a conference some structure and to inspire people, but when the only outlet for spontaneity is lightning talks or hallway cliques, it limits the life of the conference. Don’t make open-space an afterthought: give it equal prominence with the planned parts of the schedule.

Design for fun and new friendships

Free booze is one way to help people make new friends, but there are others.

Mealtimes are a good time for conversation, so having sit-down meals planned into the conference is great. Interactive workshops and hands-on sessions, as I’ve mentioned, give people more chance to get to know each other. I’ve also been to conferences where they deliberately matched up new attendees with old timers, so that the newbies had a friend from day one. I notice that GoRuCo does this, so kudos to them.

You’ll notice I haven’t included anything in this list about the selection process. I think enough has been said about that already, particularly by the good people of Ruby Manor, Nordic Ruby and Jez Humble of FlowCon. I’m making a wider point about the format, and the spirit of the conference scene.

Let’s stop promoting heroes within our community and make our conferences be more egalitarian, more exploratory, more fun.

I found myself in a session on refactoring legacy code. The session used a format that was new to me, and to most of the people in the room: a coding dojo.

Our objective, I think, was to take some very ugly, coupled code, add tests to it, and then refactor it into a better design. We had a room full of experts in TDD, refactoring, and code design. What could possibly go wrong?

One thing I learned in that session is the importance of the “no heckling on red” rule. I watched as Experienced Agile Consultant after Experienced Agile Consultant cracked under the pressure of criticism from the baying crowd of Other Experienced Agile Consultants. With so many egos in the room, everyone had an opinion about the right way to approach the problem, and nobody was shy of sharing his opinion. It was chaos!

We got almost nowhere. As each pair switched, the code lurched back and forth between different ideas for the direction it should take. When my turn came around, I tried to shut out the noise from the room, control my quivering fingers, and focus on what my pair was saying. We worked in small steps, inching towards a goal that was being ridiculed by the crowd as we worked.

The experience taught me how much coding dojo is about collaboration. The rules about when to critique code and when to stay quiet help to keep a coding dojo fun and satisfying, but they teach you bigger lessons about working with each other day to day.

Here’s the puzzle:

https://gist.github.com/912504

Can you solve it?

The idea behind the session is to simulate the life of a start-up software company. In the early rounds of the tournament, the priority for each team is to get a robot, any robot, out there an playing matches. As the tournament progresses, quality becomes more important as you need to adapt your robot to make it a better competitor.

This ability to adapt your approach to the work to the context you’re doing it in is, I think, really important for the true craftsperson to grasp. If you’ve been reading Kent Beck’s posts about start-ups and design, you’ll be familiar with this subject. It’s wonderful to be able to patiently produce a beautifully-worked piece of furniture, but what if the building is burning down and you just need a ladder to escape, right now? Can you rip up some floorboards and knock something together from the materials to hand and save your family?

There’s a great skill in understanding and working to the appropriate level of quality for the context you’re currently in, and I hope this session gives people a little insight into that.

You can watch my screencast audition for the session here. Please leave any feedback or comments here.

Narrative Journey Maps

• Duncan Prefers the term Usage-Centred Design to User-Centric Design. There was a book reference here but I missed it.
• Narrative Journey Maps (NJM) are a way to model and visualise the steps a user has to follow as they try to achieve a goal.
• Each Step is decorated with:
• Comments
• Questions
• Ideas
• An Emotional Barometer is draw across the top which highlights pain-points where the user may be particularly frustrated with the process.
• NJMs are usually created from a Contextual Study where users are quietly observed trying to reach the goal.
• They are a way to record the current state of play, and a place to start thinking about how things could change.

Personas

• Alan Cooper 1985
• Based on real data: capture and use direct observations of real experience
• Group and merge those observations to form personas
• Personas have:
• Motivations
• Goals
• Frustrations
• Behaviours

It seemed that what had worked for the presenters was to focus on just one persona at a time, when it became obvious who their core user was, and work at satisfying their needs. Once they’d started to make significant inroads into this, it became clearer and more worthwhile to look for other personas.

To Read

Luke Hohman’s Innovation Games
Mr Squiggle (seed drawings for workshop excercises)
Consensus:

• Quaker Business Method
• Sociocracy
• Formal Consensus (CT Butler)
• “Participatory Decision Making” – Sam Kaner

“The Logical Thinking Process” – H William Dettner. A book on conflict clouds.
“Round the Bend” – Neville Chute. Like Zen and The Art of Motorcycle Maintenance but English

Other Conferences

Keith Braithwaite was heading out to ‘Next Generation Testing’ and said he was really looking forward to it. He said it was quite easy to stand out from the crowd of big vendors, and that if you have something original to say you’ll likely be asked back. He also mentioned ‘Test Expo’ as being another conference in this vein.

Really interesting it taking the Cucumber message to these conferences.

Remote Pairing and Wolf-pack programming

I met several people who are making use of or would like to make use of this more. Many of them were using Ubuntu so don’t have access to iChat, and were struggling with slow VNC connections. I suggested screen + emacs/vim to a few people (not that I’ve used it myself, but I’ve heard good things). People mentioned plug-ins for eclipse, and my old favourite SubEthaEdit came up. It does feel like there’s product missing here.

Some guys did a BoF trying out a crazy contraption they had using a smalltalk environment that allowed a dozen people all edit the same code at the same time, on their own workstations. It sounded pretty amazing.

My Session

I ran a session, Robot Tournament at the conference. Despite what I had considered thorough preparation, I had some rather exciting moments when the tournament engine spluttered and needed some running repairs. Overall though the feedback I got was positive. Some observations:

• The (accidental) downtime gave people an opportunity to make build scripts and so on. I wonder whether this could be engineered deliberately another time.
• More logging and visibility of exactly what’s going on when a player runs would be useful to help participants with debugging.
• The warm-up should include calling a robot with a command-line argument so that any teething problems with reading the input can be resolved at a relaxed pace.
• A better explanation (role play?) of how the tournament works would help.
• Need to limit the number of players to 1 per team. Although it was worth experimenting with allowing more than one, there were a couple of disadvantages that seemed to outweigh the advantages:
• when people realised they could write scripts to add several robots, this really slowed down the time to run a round due to the number of permutations of matches. I guess here you could deal with this by using a league system, but for now the simplest thing seems to be to just limit the number of players.
• there is a strategy (which the winning team used) where you use a patsy player which can recognise a game against another player from the same team and throw the game, thus giving that player an advantage. By releasing several patsy players you leverage that advantage.
• I was surprised (and a bit disappointed) at how conservative most of the language choices were. I think we had 3 Ruby robots, 2 Java ones and one Haskell robot. Sadly I couldn’t get smalltalk working for the guy who wanted to use that. It seemed clear that rather than one language being particularly better than another for the problem at hand, teams who used a language they were familiar with did best.
• It was hard for people to see what was going on when they were getting their robots running. More visibility how exactly what it looks like when their program is run on the server environment would be helpful.
• Also more functionality on the UI to slice the results and look at just how your own robot had performed.
• The problem was so small that tests were hardly needed. Pivoting, changing the rules of the game half-way through the tournament might have helped here.
• I would also be interested in trying out variable-length iterations – some long ones, some short ones.
• Shipping simple solutions early was definitely a strategy that had worked for everyone.
• People enjoyed the fact that the goal – getting points – was clear, so that rather than it being about writing clean code or writing tests, it was more realistic to a business context.
• Trying a more open game where you could learn more about your opponent might be interesting
• Getting teams to swap code might also be interesting
• Doing a code show & tell wasn’t in my plan but worked really well

The session format ended up being something like this:

• 10 minutes introduction
• 25 minutes warm-up
• 30-45 minutes faffing around fixing the engine while people started to build their real robots
  break
• 7 x 7 = 50 minutes tournament rounds
• 25 minutes code show & tell
• 15 retrospective looking at what we’d learned and any insights

Here’s some more details about the conference:

Friday 14th May 2010 – UCLan, Preston

Price held at £95 per person – be there to learn, share, take part
and enjoy

Details on www.agilenorth.org

Mind if I run a couple of things past you?

I’m going to use personas in the session as a tool to help people discuss the anti-patterns that I think cause teams to struggle with pair programming. You’ll hopefully recognise yourself or people you’ve worked with in the past in these personas. What do you think? Have I missed any? Are they too obvious?

Goran, Architect

“For most tasks, pair programming just slows me down. When you pair with me, it’s not pair programming, it’s mentoring”

Goran has been programming professionally for over 15 years and draws on that experience to write clean expressive code. He can code fluently in C++, C#, Python and is handy in numerous other languages. He knows all the common design patterns and when to apply them, as well as numerous refactoring strategies.

Goran has tried pairing a few times, but doesn’t really see the benefit. He feels that his level of experience makes for rather uneven and therefore pointless pairing sessions.

Bart, Obsessive

“I just hate having to share the keyboard”

Bart is really gifted programmer who gets a huge amount done with few mistakes, but his team-mates often find it hard to understand and change his code. He’ll often use jokey or sarcastic names for variables and methods and has a tendency to write long, complex, methods. Bart drinks a lot of coffee and works long hours, often getting quite obsessed about finishing a particular piece of work.

Bart doesn’t really like the idea of pair programming. Although he understands the benefit of ‘no code ownership’ in theory, in practice he feels quite possessive about his code, and finds himself quickly becoming aggressive when discussing design decisions with other members the team. He often seems to upset his team-mates when he just thinks he’s being honest with them.

Moira, Anxious Project Manager

“My team doesn’t have time to work in pairs, we have too many bugs to fix”

Moira used to be a programmer back in the day, working on COBOL mainframe systems, so she knows the ropes. As everyone sticks to the plan, she sees no reason why things should go wrong. Right now her team are in the ‘testing phase’ of another project, and as usual there’s a frenzy of activity as bugs are uncovered by the testers and passed to the developers to be fixed.

Moira just can’t see how halving the number of bugs being worked on by adopting pair programming can help her team meet their deadline. To her, pair programming just seems like a fad that helps programmers have a better time at work.

John, Contractor

“I’m scared people will realise I don’t know what I’m doing half the time”

John is a contractor, a hired gun. He’s paid at least twice as much as most of his team-mates who are salaried. He’s experienced and highly competent, but secretly frets that he isn’t really worth the extortionate daily rate that he’s paid, and feels guilty when he gets stuck or has to ask his team-mates for help.

John has never tried pair programming but he worries how his team-mates will feel when they realise he sometimes needs to spend 20 minutes reading around blog posts and mailing list archives, or writing throw-away code to figure out how to use a library he’s never used before. Won’t they end up resenting him for wasting time?

Sarah, Wallflower

“I’m just used to programming on my own”

Sarah has been programming since her early teens and got top grades studying Artificial Intelligence at University. Sarah is naturally shy, and has always found comfort in programming as a place where she can express herself and her ideas without having to talk to people face-to-face, which she finds awkward and embarrassing. She contributes to a couple of open-source libraries and can often be found on IRC channels and mailing lists supporting the users of those libraries with friendly and eloquent responses.

For Sarah, programming has always been a solitary activity. She finds the idea of pair programming strange and quite intimidating, since she doesn’t think she’s very good with people.

Gary, Once Bitten

“Pair Programming is a load of old bollocks”

Gary has worked on a project before where the team claimed to be ‘agile’. They used Scrum and user-stories for planning their work, and the scrum-master encouraged them to use pair programming. In fact, the scrum-master forced the team to work in pairs, by picking pairs at the start of each 2-week iteration, and making sure the developers stuck to those pairs for the entire duration of the iteration.

By the end of each iteration, most of the pairs were so sick of working with each other that they would barely speak for several days afterwards. Gary found he would come in earlier and earlier so that he could get some time hacking on ideas he’d had but didn’t have the chance to play with during the main working day. He found pairing to be a drudge and a chore.

Rod, Whacky Races

“Every time I pair with someone new, I have to learn their bloody keyboard shortcuts”

Rod has just joined a new team who are using UNIX text editors to do their development in Perl. Rod is used to using the Eclipse IDE and has never really used these text editors before so he feels awkward and clumsy when he gets the keyboard. This is compounded by the fact that his team are using a mixture of editors and operating systems, with some people staunch EMACS users, others using VIM and yet more using Textmate on the Mac.

Rod likes the collaborative aspect of pairing, but feels hampered by the variety of development environments that his team uses. What can he do?

All thoughts and comments appreciated. If you’re in London tomorrow night, why not come along to the session and let us all know what you think?

Come to my talk if you want to hear my experiences of breaking a team out of the Scrum mould and doing some exciting stuff with value stream maps, Kanban boards and other techniques from the school of Lean Thinking. Come along if you want to hear about a world without task cards, exhausting planning days, and maybe even a world without estimates. Sorry Jason, but there may be some mention of coloured bits of card.

I’m actually one of only a few people with a scheduled talk, as the organisers have decided to use an open-space format this year. Which means you also have a chance to get up on stage and lead some discussion. After my last experience with an open space, I’d say it’s well worth doing your homework and really thinking about what you’d like to discuss at the conference beforehand so that you get the most out of it.

If you’re interested in building software as well as you can, XP Day is a great place to meet like-minded people, share experiences and develop ideas. It’s only small, so register soon!

Let me know in the comments if you’re coming, and what you’d like to talk about when you get there.

There’s a mixed crowd – some die-hard extreme programmers, quite a few self-styled (and self-promoting!) ‘coaches’ and a few newbies.

The atmosphere was really friendly – you would quite often find yourself sat in one session right next to the person who had been leading the previous one, so that and the often fun and interactive sessions broke the ice pretty quickly.

The first day was a bit flat for me, but after a night on the free beer courtesy of the sponsors, the second day picked up and really made it worth it. I wish I’d had time to stay for another session in the pub on Tuesday evening.

Key things I took from this conference, more detail on these later if you’re lucky:

• There’s a fairly serious backlash going on against scrum (I heard more than one person drop the ‘r’, although I think one of those was accidental!), certainly within the London / UK agile scene.
• There’s tension, which as I see it is between the coaching community and the programmer / creator community, who disagree about how much it’s OK to compromise on the original agile manifesto values and XP practices. I heard the phrase ‘valuing pragmatism over orthodoxy’ which summed it up rather well.
• Nobody, but nobody, works for ThoughtWorks anymore, not even Fred George
• You probably need to be working in Java if you want to get decent XP gigs, especially for a bank, and there’s quite a few people working for banks – particularly front office.
• Kanban is where it’s at, baby.