I spent the better part of this week in Malmö attending this years edition of Øredev. I’m really glad that I had the opportunity to go there and, while I can’t really say that I’m super psyched about some new technology or realization that dawned on me during the conference, I feel very inspired and energized.

Responsibility driven design and LEGO pirates

There was a few sessions as workshop that I particularly liked but if I were to pick one single thing that really got to me it was Jeremy Miller’s reply to a question about why we should break our code up into small components during his sessions about responsibility driven design. He responded with an analogy about LEGO. When he was a kid he used to play with regular pieces of LEGO. Though each piece were just a small block, put several of them together and you could use them to build anything you could imagine. These days Jeremy is no longer a kid and he has a son of his own. His son has a LEGO pirate ship. It’s really cool and looks just like a real pirate ship. But take it apart and look at the single piece that makes up the ship’s hull. It works great for building pirate ships but you can’t really do anything else with it.

I think that analogy was spot on. I also remember it extra well as my wife and I had been discussing old school LEGO vs. the new more realistic but, in my opinion, boring new types of LEGO just before I left for Malmö :-)

Other than the LEGO analogy Jeremy Miller’s talk about Responsibility Driven Design also had some other interesting lessons. I especially enjoyed his walkthrough of a number of “Object Role Stereotypes” that, to me, provided a vocabulary for concepts that I try to practice when I write and structure code. These stereotypes are:

Information holder

Knows things and provides information. May make calculations from the data it holds.

Structurer

Knows the relationship between objects.

Controller

Controls and directs the actions of other objects. Decides what other objects should do.

Coordinator

Reacts to events and relays the events to other objects.

Service provider

Performs a service for other objects upon request.

Interfacer

Object that provides a means to communicate with other parts of the system, external systems, infrastructure or end users. Similar to the Gateway and Facade patterns.

Keeping wiki information up to date – Crisp style

Another really clever thing that I learnt was how Henrik Kniberg had tackled the problem of wiki’s growing outdated. On Crisp’s wiki, using a simple javascript, he gradually fade in a background that makes the page look old and hard to read. The older the page the harder it is to read and the older it looks. Brilliant in it’s simplicity!

That was just one of many interesting takeaways from Henrik Kniberg’s excellent keynote about the power of visualization. Another thing from my notes from his keynote is to check out the book The 4-Hour Workweek. Yet another thing is that Rusell Ackoff seems to be an excellent source of great management quotes, or how bout “Managers who don’t know how to measure what they want settle for wanting what they can measure” and “It is better to use imprecise measures of what is wanted, rather than precise measures of what is not”.

It was also very interesting to note that EPiServer had consulted Henrik to help them with their Scrum process, only to end up using Kanban with Henrik’s help instead.

Scala’s cousin F#?

As I wrote prior to going to the conference I was pretty excited about attending Ted Neward’s Scala workshop. I hoped that it would inspire me to continue learning Scala and give me new energy to write about it in my series that seems to have come to a halt after nine posts.

While I did enjoy the workshop, and while I did learn interesting fundamentals of functional programming, it didn’t really teach me much about Scala or how to use it that I didn’t really know. Instead my biggest takeaway from the workshop was when Ted said something along the lines of “[…] and Scala’s cousin F#”. I was kind of surprised to hear that as I had thought that the two languages were very different. Sure, I knew that both are multi paradigm languages but I had thought that F# was much “weaker” on the OO side than Scala.

Anyhow, I took the opportunity to discuss the similarities of Scala, a language that has peaked my interest, and F#, a language that I haven’t been very interested in, with Ted and it really renewed my interest in F#. Not because its supposed to be a better language than Scala but because one of the reasons that I’ve not written much Scala code lately is that it’s a daunting task taking on all of the, to me, new tools used in the JVM space. With F# I can feel right at home using Visual Studio, the .NET framework and many of my favorite tools.

Koans and Katas

Perhaps the biggest positive surprise I had at Øredev was the other workshop that I went to, titled “Koans and Katas Oh My!” and held by Cory Foy. I had only picked it because I had to pick something and there really wasn’t anything else that had peaked my interest. I’m really glad that I did though!

It turned out to be a lot of fun with a lot of hands on exercises combined with some theoretical background about what koans, katas and code retreats are. I was so inspired that I almost immediately decided to hold a similar workshop, though with a slightly different focus, for my fellow Valtech colleagues as soon as possible. If that turns out well I might even hold a workshop at DevSum next year where I’m already scheduled to give a presentation.

Be sure to check out Cory’s post with his slides and links from the workshop!

Challenging Requirements

Another positive surprise was a session titled Challenging Requirements held by Gojko Adzic that I decided to attend at the last minute. During the session Gojko told a number of short stories about projects or other forms of customer relationships that he had been in where the requirements stipulated by the business would demand a lot of development time or cause other types of problems but where he had been able to uncover the real, underlying requirements and thereby been able to suggest equally good or better solutions that were much faster or easier to implement. After each story he summarized the moral of the story:

• Refuse solutions to unknown problems. Understand what the real problem is and solve that.
• Refuse suggestions to use a technology. You know IT better than they do.
• Don’t rush into solving the first problem they give you. Keep asking “why” until you get to the money.
• Know your stakeholders. Who is going to use this and why?
• Don’t start with stories! Start with a very high level example of how people will use the system.
• Great products come from understanding the real problem and whose problem it is.

I hadn’t heard about Gojko Adzic before but he was a really good speaker and he also seem to have written quite a lot interesting material in the past, among other things a series of posts about “TDD as you meant it” that Cory Foy referred to in his workshop and a book titled Bridging the Communication Gap about acceptance testing.

I’m looking forward to seeing Gojko’s other session, “Agile acceptance testing: Success stories” as soon as the video is out.

Other inspiring sessions and speakers

Yet another interesting session was Cory Foy’s “Delivering what’s right” and Aslam Khan’s “Architecture in an Agile World”. Aslam Khan was yet another person I hadn’t heard about before but his presentation style, which was very personal, was truly excellent and so was his material. I really encourage you to watch the video from the presentation once it’s out. Unfortunately I missed his other session “Truth and Reconciliation: Agile Lessons from The Rainbow Nation” that got a lot of positive feedback on Twitter.

PS. For updates about new posts, sites I find useful and the occasional rant you can follow me on Twitter. You are also most welcome to subscribe to the RSS-feed.