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.

I planned to write individual posts about new and upcoming workshops, but the rate at which we get invited and accepted to conferences this fall outstrips my ability to post new entries I have to post now, before the conferences themselves are over… I hope you’ll join us for at least one of these. We’ll be doing some hard-core programming workshops as well as more enterprise and facilitation oriented sessions this fall.

First up is Scan-Agile next Thursday and Friday in Helsinki, Finland. Marc already wrote about our Story Testing workshop.  I’m also very much looking forward to participating in the Scan-Agile Open Space, which now has its’ own day.  The main reason for me to return to Scan-Agile this year, is that last year it had very strong participants (and presenters, but good session organizers are only part of what makes a conference worthwile). Having my own unit tests ripped to shreds by critical participants was interesting and valuable. So I’m glad this year all participants get more space. We had some discussion on Twitter about ‘is kanban a failure mode of lean? (and what that means if it is so)’ that merits more than 140 characters… should make for lively open space as everybody involved in that discussion will be there . If I haven’t motivated you to join us, check out Vasco Duarte’s series of motivational posts about Scan-Agile.

Next up is the Practical Product Lines conference , October 20 and 21 in Amsterdam, Netherlands. There we will be hosting a value stream mapping workshop, as described by Marc. We decided to try out more conferences outside our regular schedule of agile conferences – preaching to the choir is fun, and helps us improve our understanding, but going out into the world and sharing what we’ve learned is at leas as valuable. We thought it would be interesting to bring our understanding of value stream mapping, and take participants’ experiences with product lines, should provide an interesting mix.

Freek Leemhuis of Devnology asked us to send in some proposals for the Devnology community day, saturday November 7 in Baarn, Netherlands.  We did, and they chose three of QWAN’s sessions for the program:

Refactoring to concurrency (with Scala) grew out of a series of commits I did for a product I’m developing with Marc, micro-ISV style. We needed some background processing to make our application more responsive, and I wanted to take small steps, be sure that it worked and have everything covered with tests. So I first refactored, until introducing concurrency was just a one character change. This session shows you how to do the same thing, with scala or another language.

Flying Horses – cleaner code in other languages. This session was inspired by a dojo description from Emily Bache (I don’t have the link handy right now, will insert it later). Rob ran with it and tried it out at Agile Open Holland last month. We’ll bring an application written in one language, everybody gets their laptops, a pair to program with and translates that to their favourite language. At first as literally as possible, and then make it ‘more like their language’. Then we will discuss what makes code, e.g. pythonic, javaic, C-sharpish etc. based on the examples we just created.

Give your code some love is a demonstration (a series of prepared katas) of us doing tiny refactorings on code that looks allright at first glance. Tiny refactorings then show that there are quite a lot of things we can do to make the code express its’ intent better. This session was heavily inspired by Ivan Moor and British Mike Hill ’s Programming In The Small workshop at the software craftsmanship conference in London earlier this year.

Jfall, conference of the Dutch Java Users’ group, November 11 in Bussum, Netherlands, sees Rob and me doing TDD As If You Meant It, inspired by Keith Braithwaite’s session of the same name at, again, the software crafsmanship conference in London. Keith kindly gave us permission to reuse the name. We are happy to see more people applying unit testing. Very few, however, seem to be really doing Test Driven Development. In this demonstration we hope to give the audience a taste of what test-first programming can do for you.

Xp Days Benelux, November 23 and 24, Mechelen, Belgium I already described Retrospective Hero with Nicole Belilos of Task24 and Agile Politics – (re)discover the politician in you at XP Days Benelux with Emmanuel Gaillot of Pyxis

and Finally, XpDay London, December 7 and 8th where I’ll be pair facilitating the Open Space with Rachel Davies.

Wille Faler asked on Twitter earlier this week about how people who go to conferences a lot do work. All of the conferences above are one, maximum two days, that leaves plenty of time in the rest of the week to do ‘actual’ work.  The other thing is, writing is a poor medium (for me at least, even though my blog does seem to travel reasonably well these days) to show our passion for software development, going out to conferences helps us connect with other people who are equally passionate about our profession. And sometimes this then leads to actual work. Which leads me to the following:

Shameless plug:

At the moment I’m looking for a new project to work on, either as a developer, agile coach and/or project leader. contact me if you know of a place where my skills would add value. Also, all of the sessions above and more are available as customized in-house training.

Dancing Peacock by Hamed Saber

Here’s why:

As a writer, I want photos to go with my blog entry, so that it looks appealing for readers and inspires me to write more.

Brickpit Ring Walk Bicentenial Park by Louise Docker

As a presenter, I want photos to go with my slide, so the slides have metaphors that make people think, and my presentations look well prepared.

For these two stories we might not have bothered writing a web application – we could use the regular flickr search. However:

As a writer or presenter, I want to easily credit the photographer so that I can fulfill the obligations that go with the license and give viewers the opportunity to see more of their work.

I used to have Super Human Powers by Esparta Palma

We found that finding photos to go with a presentation was easy enough, but collecting the credits and then adding an attribution to the photo in a blog entry or the end of a presentation) often turned out to be a lot of clicks, which meant that we would not add photos to presentations as often as we like…

How does it work?

Photo Suggest queries Flickr and searches for photos with a liberal license (see the about page for a short list) sorted by interestingness. If you click on the link below an image, it takes you to the details page that shows the full credits, license and description together with the image. The reason we called it ’suggest’ is that when you type a keyword, the results are often not what you’d expect, but can more often than not make an interesting contribution to your text.

How did we get here?

With QWAN we try to apply lean and agile principles to everything we do, so we reflect at our ways of working continuously, identify things that add value, and do more of them, as well as things that are wasteful and eliminate them. We started to give more and more presentations to get the word out – we love experiential sessions over anything else, but they do not get us into more traditional conferences. Styles like Presentation Zen led us to do more with images.

Presentations with attractive imagery inspire me more when I do a presentation and they seem to energize the audience as well, so it becomes easier to add experiential elements (small exercises, questions) to a presentation.

Marc Evers and I have been thinking about how to improve our presentations as well as the way we produce them for a while. This led to a bunch of wild ideas, which we used as stories for the new new new! product development game – participants have to plan a ‘presentation 3.0′ project.

With Lasse Koskela I ran a Scrapheap Challenge at XP2009 – participants have to write a working application in half an hour. For that we needed exercises. Some stories from the game seemed well suited, so I did a small experiment – in half an hour I got quite far. Then I called Marc and asked him if he wanted to help me finish it into a working application. We had noticed we were losing some of our “superhuman powers” , so Marc suggested to “start from production”, which meant I talked him through the app while we brought it into version control and production, before adding more features & polish.

From experiment to production took half a day. After a day it was usable enough (but was missing the finish such as about page and stylesheet) for us for blog entries and presentations. When we demoed it during xp2009 a few participants jotted down the url, which encouraged us to polish and publish it.

What Can We Do With Flickr? by Alan Levine

We hope you enjoy it! Your feedback is welcome.

Haskell

This years’ conference had many sessions on a hitherto rather obscure programming language: Haskell. I knew the guys from the Paris CodingDojo (at the very least EmmanuelGaillot, ChristopheThibaut and ArnaudBailly ) have been jamming on Haskell for a while, I was surprised to learn Ivan Moore and Mike Hill, this years’ programme chairs also have taken an interest in it.

I am not exactly sure why. Maybe it is because Haskell is the ultimate MindFuck where it comes to programming languages that you could use in theory (and sometimes in practice) to do interesting stuff. Maybe it is because, if you do not work in really, really small steps, you are going to shoot yourself in the foot very quickly, so Haskell, TDD and a dojo (where in the randori form you have only 5 minutes at the keyboard before you have to rotate out) seem like a natural fit.

Ivan told me they thought it would be interestingly different to let Simon Peyton-Jones, one of the stewards of Haskell, do a keynote. SPA has a tradition of keynotes that are inspiring and different from what you would expect – Kent Beck did early presentations on eXtreme Programming at this conference (then named OT) 10 years ago.

Simon Peyton-Jones presenting the keynote on Haskell

The keynote was fun and interesting, explaining the kind of problems Haskell intends to solve, with some examples. You could say haskell is kind of a spreadsheet on steroids, although it lacks the graphics . The presentation was laced with code on slides, explaining important features in Haskell. About halfway through, unique for a keynote, Simon did some live coding, showing how the haskell program quicktest can be used to test new features. Quicktest exercises code with random testdata for cases specified in haskell, and when a test fails reasons backwards to find the simplest possible failure.

Apparently Arnaud Bailly and Christophe Thibaut used quicktest in their workshop on wednesday to test a java program, I would have loved to see it, but had to be at our Consulting Without Secrets workshop, which was good fun in itself and very useful for running our businesses; you can read through the outputs on the conference wiki.

Back to Haskell.  Sunday saw the RealWorldHaskell tutorial hosted by Peter Marks, Nicholas Simons and Ben Moseley. Christophe Thibaut paired with me, so we could work test-first. Unit testing was not part of the tutorial, but Christophe already knew how to do it. This helped us to getting reasonably far with the exercises.  If you do not work in small steps, I find the error messages sometimes difficult to understand.

Several Bird of a Feather sessions were scheduled to do more Haskell in the form of coding dojos. There was also a discussion BoF on why Haskell? which was packed – more people attended that than the hands-on sessions, which I found a bit puzzling. The dojos consisted of a Kata performed by Christophe and Arnaud, and a Randori hosted by Rob Westgeest. That meant I got to practice a little Haskell with switched-on colleagues every day. Pair programming and learning helped a lot.

Therefore, next Tuesday, April 28th, Mike Hill and I will be co-hosting an amateur Haskell coders’ dojo at the eXtreme Tuesday Club (in London of course).

Beatboxing

The SPA conference always has interesting ‘diversions’ in the evenings. Before the whiskey tasting there was a beatboxing tutorial, hosted by UK beatboxing championship Mc Zani. That was wicked.

Here you can see him in action for a ’slightly’ larger audience. Mc Zani knows his stuff and his facilitation style resulted in a relaxed workshop with surprising performances by some of the participants . Definetely worth it to attend one of his workshops if you get the chance.

Some of the remarks Mc Zani made about beatboxing made me think of programming, and the agile movement. Beatboxing is more than a party trick, but after it suddenly became popular again, the media are overflowing with mediocre beatboxers – people who see it as a party trick and are not willing to put in the effort required for greatness. Great beatboxers are still out there of course, but you have to go look for them.

Which brings us to the next topic:

Anarchy Agility in the UK

The other diversion was a Panel Discussion about 10 years of agility in the UK and bar night, with drinks sponsored by the eXtreme Tuesday Club . David Harvey hosted a panel discussion between early eXtreme Programmers Paul Dyson, Tim Mackinnon, Rachael Davies and Ivan Moore. Paul Dyson wrote about his optimism already:

Perhaps the Agile community has become a bit too focussed on certification rather than learning, on easy rather than effective methods, and on being recognised as ‘being Agile’ rather than achieving agility. But I believe that the world is changing in a way that will force the Agile community to adapt or die and I’m optimistic that we will achieve the former.

Paul was was a bit surprised about the agreement on failing agile projects in the room – since it was filled with agile coaches, developers etc. who have a ‘vested interest’ in agile. I have a vested interest (I am not retired by a long shot , coaching and training agile teams, and being test-infected I have to find places of work where I can at least write tests  (and preferably talk to the customers as well) . The agreement does not surprise me.

I still encounter shops (or rather, shops encounter me) that want to kick ass, but as ‘agile’ becomes mainstream we find more and more shops that are content to go throug the motions, or believe that by following some book ‘to the letter’ they will be somewhat more successful. I guess the room was filled with people who got addicted to high performance teams through the early days of eXtreme Programming. Stepping back from there into environments that lack the desire for excellence is hard.

Another thing that struck me from the panel discussion, was a remark by Tim or Paul about the early days of XTC. If something new came along, you would try it out just for fun and see if it would work for you. These days there seems to be more of a ‘not invented here’ syndrome hanging around, even in agile circles.

Paul’s optimism stems from the trend of mash-ups – applications that are made from other applications that already exist. Turn-around time of mash-ups can be a lot faster than ‘traditional’ applications, which will force the agile community to adapt or die (or perhaps ‘adapt or dye’   ).  In that context the postmodern programming conference organized by Ivan Moore and others a few years ago was also mentioned.

Lasse Koskela and yours truly already decided to adapt (embrace and extend ) – we will be hosting a Scrapheap Challenge, which is a shorter version of the exercises of the postmodern programming conference, during XP2009. We see the internet as a giant Scrapheap, and Challenge the participants to complete a mash-up instead of an application, from Scap instead of Scratch, in less than no-time.

In the meantime, I hope the photos convey a bit of the buzz that was SPA2009…

a “ development project for bored consultants”

contact Johannes if you’d like to spend (at least) one day per month in a project with other agile consultants and you are willing to give this project priority on that day.

I believe a regular programming project with like-minded programmers this is a great idea. Programming is a long haul activity, some effects you only notice after a while, and jamming with fellow practitioners is a great way to learn.  The reason I support Johannes’ idea is because I believe it will support participants in sharpening their saw – increase understanding of what they already know by spending time doing programing work and reflecting on it, as well as creating a space where experimentation is not an option – it is a requirement

A Lady's saw - by KaCey97007

As a consultant I am most often hired to explain what I consider to be “the basics”. This is a moving target of course, as my understanding of “the basics” changes with experience. When I started out coaching teams, I did a great deal more experimentation on client projects, as I was learning “the basics” together with my clients. There is nothing wrong with doing “the basics” again and again, that is also a way to deepen your understanding of a subject. Kata’s in a coding dojo work like that – coding dojos are another way to keep up your programming skills.

However, keeping up is not enough. I am lucky in the sense that I have been able to keep up my programming skills by teaching technical workshops and doing hands-on coaching on client projects occasionally. I’m starting on another hands-on project for a client in a couple of weeks, where we will pay quite a bit of attention to “the basics” and everyone (including me) will learn some new things.

However, client projects are not always a good place to try out experimental stuff that has not been proven yet – that requires visionary customers with some slack in their organisation. And quite frankly, my customers often benefit more from my understanding of what I already know than from my desire for experimentation and learning (which I then satisfy by learning about their domain instead).

Therefore, having a separate project to regularly practice practices and having the space to try things out is good. I’m lucky: with my partners in QWAN we came to some of the same conclusions as Johannes. We need to be able to spend significant time developing with other visionary developers so that we can advance the state of our practice. We decided to develop new hands-on programming workshops with challenging excercises – beyond our current understanding of “the basics” and start developing some (mini-) products together. We did that because we needed some software to support our business, have some wild ideas, and last but not least wanted to sharpen our saw.

We want to improve our programming skills in an organisation that has the vision and slack to support it (e.g. our own ), because keeping up is not enough.