Are Ruby conferences taking us in the wrong direction?

I just got back from Baruco. I had a wonderful time, made new friends and caught up with some old ones. but I was still left with a concern. That’s what this post is about.

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.

Ruby Programming

Comments (0)

Permalink

A coding dojo story

It was 2008, and I was at the CITCON conference in Amsterdam. I’d only started going to conferences that year, and was feeling as intimidated as I was inspired by the depth of experience in the people I was meeting. It seemed like everyone at CITCON had written a book, their own mocking framework, or both.

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.

Agile / Lean Software Development

Comments (0)

Permalink

A Puzzle for Polite Ruby Programmers

I really enjoyed Jim Weirich’s session on polite programming at the Scottish Ruby Conference. He covered a problem that’s been vexing me for some time, about avoiding the use of method aliasing, by using inheritance instead. Unfortunately, his suggested solution didn’t tell me anything I hadn’t already tried. I still think this must be possible, but that I just don’t know quite enough about Ruby to be able to achieve it. Maybe you do?

Here’s the puzzle:

https://gist.github.com/912504

Can you solve it?

Ruby Programming

Comments (2)

Permalink

Battling Robots at Software Craftsmanship 2010

I’ve submitted a session for the Software Craftsmanship 2010 Conference. It’s a redux of the Robot Tournament I ran at SPA2010.

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.

Agile / Lean Software Development

Comments (0)

Permalink

Random Notes from SPA2010

Usage-Centric Design

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

Agile / Lean Software Development

Comments (1)

Permalink

Agile North 2010

I’ll be speaking at Agile North this year. The title of my talk is “The Lean Startup”, in which I’ll describe my experiences with an incredible young company I’ve been working with for the last couple of years.

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

Agile / Lean Software Development

Comments (0)

Permalink

Personas for Debugging Pair Programming Session

As I may have mentioned I’m running a session at Agile 2009 called ‘Debugging Pair Programming’. There’s a preview of the session tomorrow night at Skills Matter and I’ve just finished preparing for it.

Mind if I run a couple of things past you?

Continue Reading »

Agile / Lean Software Development

Comments (6)

Permalink

I am Extreme

I going to be speaking (with my good friend Rob Bowley) at the forthcoming XP Day conference in London, 11th & 12th December 2008. Which means that I am now officially extreme. Dude.

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.

Agile / Lean Software Development

Comments (0)

Permalink

XP Day 2007

…was good fun, and well worth a couple of days off.

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.

Agile / Lean Software Development

Comments (0)

Permalink