This describes the conferences I’m attending this fall and the sessions I’m running reasonably well. I’m even assuming Java works, which seems to be more and more of a stretch for the near future .

What have I been up to so far? The Belgian Lean and Kanban conference a few weeks ago attracted quite a lot of people new to agile and lean software development. Rob Westgeest and yours truly also presented at a private conference for the dutch tax authorities, we never ex pected to have a room packed with over 120 people for an extreme extreme (duplication intentional. TDD as if you really meant it is an exercise we learnt from Keith Braithwaite) test driven development demonstration. The agilecomes to you vendor event at which I did some systems thinking was also a lot of fun; the panel discussion afterwards prepared with focused questionnaire by Jeffrey Fredrick and colleagues was very effective – the audience shared a few concerns, so we could answer a couple of questions in depth. For instance, several people were wondering about writing down requirements (they wondered about the how, the presenters wondered about the why ), and their angles were different: some wanted to know how to combine working with stories and iterations with medium term strategy, while others were concerned with demands for documentation from the organisation. Which of course led to a couple of why questions from the panelists .

It’s fun to see crowds gathering for things I’ve cared about for a couple of years, and it is even better to see extremists of various sorts look over their fences and see what we have in common again, like in the ‘good old days’ of the agile manifesto. at, just in case you are wondering what I’m doing at the scrum gathering Amsterdam, November 15-17 – this will be the first scrum gathering I’ll attend, thanks to the invitation by Tobias Mayer and Gerry Kirk to host a ‘deep dive’ into extreme programming practices that complement scrum (and kanban) well. This gathering will also feature a Kanban deep dive. On the other extreme, I’ll be attending the software craftsmanship conference in Bletchley Park tomorrow; besides focusing on people and process really getting to know your tools and techniques to actually build stuff also works.

During the debrief of Steve Freeman’s Paradigms of Programming: Hands On workshop an interesting side discussion emerged about the origins of object oriented programming. Steve’s quote of Ivan Sutherland struck a chord:

"I didn't know it was hard"

Ivan Sutherland invented the graphical user interface and the lightpen, as well as object oriented programming (he talked about “hens and chickens” instead of objects, a bit more poetic ). I found the quote Steve mentioned on Wikipedia:

“How could you possibly have done the first interactive graphics program, the first non-procedural programming language, the first object oriented software system, all in one year?” Ivan replied: “Well, I didn’t know it was hard.”

Ivan Sutherland with Sketchpad

I’m not sure whether Steve and Michael Feathers (his co-host who was stuck in the USA) intended to have ‘creating a programming language is not hard, as long as you don’t think about it’ as a feature of the workshop, but thinking about it afterwards, every single one of us participated in the design of no less than four programming languages in the space of a few hours! Armed with nothing more than pens, papers, peers and a high level description of the language features we managed to create programming languages that were expressive enough to solve the problem at hand. To be fair, we created examples of programming languages and reasoned about how the examples would run in our programming language. But still, the process felt pretty fluid.

Some things, like designing a programming language are hard, if you think about them a lot. I recently wanted to do more with drawing, as developing and communicating ideas visually is often a lot more effective than working with words alone. I started to ask people who were facilitating with visuals (Rachel Davies, Serge Beaumont) or drawing comics (Chris Matts) how they went about it, and I got a few books on drawing. The overall feeling I took away from it, is that it is easy, as long as you don’t believe that it is difficult; drawing doesn’t have to be hard, as long as you don’t believe it has to be art.

What are the things you are doing that other people believe are hard, while you do it easily? What are the things you believe to be hard, that might be easy if you just stopped thinking about it?

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.

I intended to write about other things than just conferences, but SPA 2010 is going to be too much fun to let you miss it, so I’ll break my own rules…

At the GOOS Gaggle I heard David Harvey praise the upcoming SPA conference because of its’ great keynotes (and yes, they are going to be fantastic). But to me SPA is not a sit-back and relax conference. The main reason why I’m going are the hands-on sessions and simulations. This year we’ve got even more hands-on sessions than last year, so much so that we’ve got more than a complete software craftsmanship track. Whether you are just a programmer and like to program with your peers, or you fancy yourself a software martial artist sweating it out in the coding dojo with fellow code-okas, this should be a lot of fun and very effective learning and experimentation. The language track (to introduce and explore various programming languages) also has lots of hands on sessions. This year for instance on Scala and Clojure, and if you are lazy Haskell is present like at SPA2009, but now from a more day-to-day development angle.

Of course, if you want to rest (or don’t program at all) there’s good discussions to be had in the design track (and even there several hands-on sessions) and simulation games in the People and Process track.

I still don’t know what to say exactly about Agile Open Holland 2009, even though it was a couple of weeks ago already. I’ll let the photos taken by Sander, Lucia, see also the video she made) and by Laurens at the event speak for themselves. Starting with some photos by Sander:

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.

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

We are partnering with local companies to provide our training curriculum in other countries. We started the Mastering Unit Testing course after we found many teams have started writing unit tests, but very few have experienced the benefits of hard-core test-driven development.

“You have some experience writing unit tests, but wonder how you could get more out of unit testing. Register for the Mastering Unit Testing training to experience how test driven development can make development faster and more enjoyable. You’ll learn how working test-first lets you create better designed code, and understand why unit testing techniques that are ‘simple’ in theory can be difficult to practice. Past participants have experienced less defects in production code, as well as higher velocity, which leads to happier clients and more fun in your job!”

Barry Evans works as an independent consultant and writer, and is based in France and the UK. I met Barry a few years ago at Agile Open in Belgium, when he was working as a senior coach in BT’s large-scale Agile introduction. Now we’ve done an interview to find out more about his new book “The Trousers of Reality”.

Willem: So Barry, When did you start thinking about writing a book?
Barry: I have always been a writer. I come from a literary family and it was always something I wanted to do..Willem: what triggered you to write this one?
Barry: I started writing this book when I realised I had something to say and I had enough life experience behind me.Read the rest of this entry »

If you believe corporate politics is something for ‘those dirty managers’ think again. Everybody behaves in a political way when a limited amount of resources has to be divided over groups of people. Come play our game and experience firsthand how dirty a politician you are!