Claudio Perrone’s Monologues

Øredev, the largest technical conference in Sweden, has left a profound impression on me. I’ve never felt such a sense of community and purpose in an event of these proportions before.

The constant exchange of ideas and points of view was incredible. I loved seeing attendees and exhibitors taking as much of an active role as the speakers (check Chris‘ article, for a brilliant example of creativity at work). It was like witnessing 900 people putting aside their differences and fulfilling their social responsibility to share their experiences with everyone else.

I am truly honored to have played even a tiny part in this fantastic event. My Agile Tales session went really well, at least judging by the warm feedback and the emails that I’m still receiving!

The organizers made a recording of all talks and I can’t wait to see them published at the oredev.org website. Of all the sessions that I’ve seen, I particularly loved Aslam’s content and presentation style. I’m definitely going to dissect and steal some of his ideas in the future

In many ways, the moments I treasure the most, however, happened outside the session rooms; I spent a lot of quality time meeting many interesting and diverse people in the corridors, at the local pub in the evenings, or even in the hotel at breakfast. Inevitably, nobody recorded those precious fragments, but never mind.

I was also particularly pleased to see Aspects of Leadership, Agile, Alt.NET and Domain-Driven Design being treated as first-class citizens, with dedicated tracks and great speakers.

Is Øredev the best conference I have ever been to? Quite possibly.

Frankly, I’m growing tired of product/vendor-driven conferences that are almost exclusively versed into a single technology platform. Don’t get me wrong. They play an important role but, unfortunately, they hardly attempt to address any of the most fundamental issues that we face in our industry. As my awareness grows, so are my pragmatic needs for better and broader education.

Thanks so much to Michael Tiberg, Emily Holweck and their entire crew for organizing such a sophisticated and enjoyable conference. I hope I will be there again next year.

While people are still debating about the reasons behind Oslo, the forthcoming modeling platform officially disclosed at PDC a couple of weeks ago, I thought it would be useful to share with you how, this weekend, I used MGrammar to parse plain text stories and scenarios using the Behavior-Driven Development (BDD) language originally devised by my good friend Dan North.
One of the main ideas around BDD is that we can adopt a simple language for expressing business requirements that is ubiquitous among “customers” (business analysts), testers and developers.
At the simplest level, a story may be expressed using this template (emphasis on bold is mine):

Story: <title>
As <role>
I want <feature>
So that <business reason>

In other words, a customer may write something along these lines:

Story: View music chart
As a music fan
I want to browse a list of popular songs
So that I can be motivated to buy something from the catalog

One of the immediate benefits of using this convention is that high-level requirements can be described and manipulated consistently and succinctly.
I’m particularly fond of the So that step: if well written, it often highlights the actual customer needs.
Once a need is identified, it becomes much easier for the development team to find further (and often cheaper) alternatives to the requested feature!

In the example above, “browse a list of popular songs” is the request, but being “motivated to buy something from the catalog” is the actual need. Can you imagine other features that would motivate customers to buy more? I certainly do.
The lesson here is that, almost invariably, customers request a longer antenna when they actually need a better reception. Trust me, this kind of deliberate creative thinking on finding alternatives can save you days, weeks, or even months of work.

Identifying the need is so important, in fact, that others proposed the following alternative convention, so that you can force users to put the reason of the requirement at the beginning:

In order to be motivated to buy something
As a music fan
I want to browse a list of popular songs

Are you still with me? Good. Let’s move on and discuss scenarios.
Differently from conventional, “fully dressed” use cases that I used years ago, a user story is usually written on a small card which acts as a placeholder for a subsequent conversation with the development team.
When the conversation takes place, the team would ask the customer questions such as: “what do you mean by that exactly?” To express and clarify the details of each story we write down a few scenarios:
Here, BDD can help us again with another template:

Scenario: <title>
Given <some initial context>
And <some more context>
…
When <some event occurs>
Then <ensure outcome>
And <some more outcome>
…

For example, customers, testers and/or developers could write and discuss the following:

Scenario: Browse chart
Given visitor is logged in
And visitor is on home page
When visitor clicks on chart page link
Then page should display title “Top charts”
And page should display list of top songs

These scenarios can be used as both documentation and as acceptance criteria.
If you are new to BDD, there is a little twist. Each single step in the scenario is sufficiently small to be “automated”.

Indeed, there are already several frameworks (some more mature than others) that have story runners able to relate the intention (expressed by customers) to some code (written by developers), often using a simple naming conventions (e.g. a Given step can run an equivalent Given method). The list is growing fast: JBehave, RBehave, NBehave, RSPec, Cucumber, and so on.
At InnerWorkings, we experimented for a long time with various frameworks (including our own) but we now use a Ruby-based framework called Cucumber (a brilliant rewrite of the RSpec story runner, now deprecated).
Great stuff, you will say, but I don’t want to use Ruby. Your loss, I would reply :-). We love .NET too, but we use Ruby as well.

Although I’m sure many plain-text story runners based on .NET will emerge soon (if they are not there already), this weekend I started my own pet projet. Since it uses the new language ‘M’ (MGrammar, specifically) I decided to call it MisBehave.
I haven’t bothered building a story runner yet, but you may find this picture quite interesting:

It shows Intellipad, one of the tools provided with the Oslo CTP.

On the left column, I have an instance of the language. On the central column, I have the grammar I wrote, and the third column, shows the projected tree structure. So far, I have plain text converted into a structure that will be further processed by a program. Hopefully you can see where this is going.

I haven’t tested the grammar extensively. I will clean it up, add support for scenario reuse (GivenScenario), add FIT-style tables, improve the error notifications, and refine the projections.

A few people said that writing languages is difficult. Well, it is difficult indeed if you write general purpose languages.
For simple domain-specific languages though, the task is much simpler. I wish I could say it is really trivial, but I won’t

For educational purposes, you can download my grammar here (useful if you have the Oslo SDK).
Any feedback is more than welcome.
Now I’ll better stop toying around and start preparing for my presentation at Øredev!

I’m just back from the Professional Developer Conference (PDC) in Los Angeles. I feel so jet-lagged that I don’t even know what time it is anymore. It’s dark and surely I should sleep, but my fingers keep typing on the keyboard as if they were taking on a life of their own.

Thanks to “Oslo“, the new platform for model-driven applications, I’m creating a simple textual Domain Specific Language (DSL). It’s a throwaway project, but I know my next one will be more ambitious.

I take another glance at the MGrammar language specification and I’m ready to code again. I expand my running example a bit to explore a potential scenario. Intellipad’s dynamic parser evaluates my language on the fly and duly reports some errors. No problem. I extend my grammar a tiny little more until I have no further warnings. I figured I can design my language interactively by example: it’s fun and totally test-driven!

I stare out my window for a moment, dreaming about a possible future. Writing DSL parsers is becoming such a trivial job that the need for many pesky visual DSL designers, noisy XML configuration files, and messy code-generation solutions may soon fade. With the exception of few notable scenarios (e.g. data transmission), I may very well enjoy the end of XML’s supremacy as a default file format.

I know, it’s just a dream. I’ll better go back to my task and write some more code.