Cleaner code in other languages

Monday, May 17th, 2010

At SPA2010 Rob Westgeest, Marc Evers and yours truly hosted the workshop “Flying horses, Cleaner code in other languages”. This is a quick writeup accompanied by the flipcharts that were created by the groups to summarize what they learned.

We brought one exercise, to be carried out by pair programming. A pair can choose what ever programming language they want to use. We try of course to get an interesting variety of languages to learn from. We ran three 40 minute timeboxes. Each timebox consists of 25 minutes for actual work, and 15 minutes reflecting (about three different solutions presented on the projector accompanied by discussion). Some people switch pairs from one timebox to the next, so they can get hands-on experience of trying to solve the same problem in different languages. The goal of the exercise is not to finish first, or have the cleverest solution, but develop a solution that is idiomatic in the language one is solving it in, so that we could compare notes afterwards.

This time we had three pairs working in smalltalk (cincom smalltalk as well as squeak), two pairs in ruby, two java, and further pairs in Scala and Haskell.

A few pairs wrote examples using Rspec or Scalaspec, most pairs wrote ‘classic’ XUnit style tests. Some worked completely outside-in, other bottom up, and quite a few from the middle outward (me and my pair amongst others).

Some things that struck me:

  • at least one of the smalltalk solutions I saw did not strike me as very idiomatic smalltalk (admittedly, the presenter said it needed refactoring, so they went for make it work/make it right).
  • Nat Pryce noticed that collections were processed easier (and with less code) in the Haskell and Smalltalk solutions than in Java.
  • The smalltalk pairs were the first ones to finish setting up their development environment and getting to work (Rob did a timecheck, the smalltalkers were the only ones working on the problem already). Having an environment that contains almost all the tools and libraries that you need gives a big speed boost at the beginning. What was more striking still was that all smalltalkers used environments they just installed and had not used before; I installed squeak last weekend, the others were using a fresh beta version of their environment.
  • Many people had not seen (much of) haskell/ruby/smalltalk style of iterating over collections using blocks/closures, luckily these idioms seem to be trickling down to Java and C#.

As with the previous instance of Flying Horses, the Haskell pair was moving towards a complete solution the fastest. This may be because the exercise we use seems to find itself in Haskell’s sweet spot (parsing and manipulating data).

On the whole, the level of engagement was pretty intense (about half the participants continued working through the breaks, even though we emphatically tried to get them to stop ;) ), participants said they got to see some very different ways of solving a problem from what they knew, so they came out of the workshop with puzzles to investigate further.

As one participant mentioned, code presentations work up to a point. They show what a pair has done, but it is hard to see what steps they have taken to get to the solution. Seeing the sequence of steps (and experiencing it) when you are part of a pair (especially with someone you don’t know) is very valuable. I’m interested in suggestions for getting more of the sequence of events (rather than the solution) out into the presentations.

We have tried letting people work with task lists and presenting from there (works somewhat, but may cause pairs to loose to much time on their small design up front).

Let a thousand languages bloom ;) Below are the flipcharts summarizing some of the things people learnt from the workshop.

Retrospective Hero

Monday, September 21st, 2009

Retrospective Hero is a new simulation / role playing workshop I’m developing with Nicole Belilos of Task24. The goal is to let facilitators experience several situations that can happen in real life, and let them experiment with facilitation techniques to make the most of a situation. This is a report of the trial run we held at Agile Open Holland 2009, with an explanation on how the workshop works.

Sandra, one of the product owners, explains her point of view, Serge listens intently as facilitator

Sandra, one of the product owners, explains her point of view, Serge listens intently as facilitator

(more…)

tryout labour turnover June 17th

Tuesday, June 10th, 2008

Nicole Belilos and I are hosting a trial run of our ‘labour turnover – should I stay or should I go’ workshop – we’re going to also run it during agile2008. We’re doing a trial run next tuesday (June 17th) at the office of Topic in Best. Contact me or Nicole if you want to join. If you want to know more, read the workshop description, or the full trial description in Dutch (below).
(more…)

Drawing Carousel at Agile2006

Friday, August 4th, 2006

The drawing carousel Marc and I ran at agile2006 did not run as expected (in a good way) I called Vera Peeters, who originally designed the workshop, to tell her how it went. So far every drawing carousel we have ran is interestingly different in some way, we are puzzling on causes, so we can get more people to experience the flow resulting from promiscuously pairing in short episodes.

We had a somewhat smallish audience, so we assembled one team. Team dynamics were great. After strictly facilitating iteration reviews and standup meetings the team started to self-organise these. The team started to quickly decide pair rotation, and many decisions were taken through osmosis – as pairs rotated, information was spread around, so not everything needed to be discussed at the reflection and standup meetings.

One of those things, as we discovered during the session debrief, was that the team did not deliver a drawing, but more of a collage made of cutouts. We asked how that had happened, because we had been present at all of the iteration reflections and standups, and we were still surprised by the result. Cutting was not mentioned during the meetings (or at least, we did not notice…). The team said consensus on cutting was reached within the first three iterations, solely through pairing.

The team also asked difficult questions before the first iteration (I won’t mention the questions here, as that may spoil a future run…). Having one or more experienced testers, who are skilled in looking for holes and asking critical questions, in the team present at the first planning meeting helped in preventing rework early on.

The team had gotten into the zone / flow, where the team operated as one.

Factors that may have contributed to this:

  • good mix of experienced agilista’s and ‘newbies’ – getting the ‘innocent newbie questions’ often expose holes in product and process – it also makes the debriefs easier to facilitate, as what happens in the simulation is,through the questions, easier to tie to real life
  • Running it with only one team gave Marc and me ample time to discuss facilitation strategies during the drawing episodes. We were also able to pick up more keys from observation.
  • Lynne Azpeitia was in the room as well, mostly observing, that gave us even more information to steer the session.
  • There was no competion on resources with other teams (if there are more teams, the limited number of scissors, glue sticks and sticky tape rolls leads to resource competition and wait times – teams are not allowed to change tools while drawing, only after the standup and before restarting drawing.).

In hindsight, I did get a key for the team making cutouts. At one point, the team ran out of scissors. We had about five pairs, and four scissors… If they were mainly drawing, they would not need that many scissor.
uncommented photo img_0764.jpg

uncommented photo img_0767.jpg

pair drawing

uncommented photo img_0768.jpg

switched pairs
uncommented photo img_0766.jpg

uncommented photo img_0778.jpg

drawing and cutting a prototype

uncommented photo img_0771.jpg

standup

uncommented photo img_0785.jpg

standup with list of tasks on the flipchart in the background

uncommented photo img_0783.jpg

Editing the task list

uncommented photo img_0802.jpg

drawing signed with business cards (some business cards were created on the spot with mini-index cards)

uncommented photo img_0800.jpg

The team proudly presents their result

See also Other entries about drawing carousel, mainly photos from previous runs.