Tea-Driven Development

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.

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?

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.

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

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

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 »

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.

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