On 1st and 2nd of December, the last edition of Conferencia Agile Spain was held in Vitoria. I was part of the oragnisation and both as a organiser and as attendee I think it was awesome (post with some of the internals will come soon). I held a workshop about Event Storming there, which went great. Chris Matts did the opening keynote and he attended my workshop too. In the middle of the workshop he approached to me and told me: “If you want, after the workshop I can explain you how can you join Event Storming and Real Options.” Of course! I said.

So, along with Silvia Calvet and another guy who I can’t remember his name (sorry about that mate!), Chris did a one hour master class about Risk Management and Business Analysis. For me it was the best session of the conference and it wasn’t in the agenda :-)

The summary of the master class could be: “Event Storming is a great tool when you know what do you need to do, but there’s a bunch of very important activities that you have to make before getting to this point.” And after the explanation (and with my limited experience in this part of the development of a product) I agree. Event Storming a great tool even for discovering hidden points in your domain and your solution, but its position is further down in the list of activities to do when releasing a product. It would be great to know Alberto Brandolini’s opinion about this point.

So, what Chris Matt’s think the process should be? Let me explain you with the example he used. Bear in mind that he did a basic summary of all of his experience, I’m sure there’s a lot more.

Imagine that you want to produce something that helps you to make tea (a teabag, basically). First of all you need to study the needs of your users? Why they need a teabag? To make and drink some tea? Or maybe to change the colour of their curry?

teabag

Let’s say we want to drink some tea. What are the needs we want to fulfil? Could be a bunch of them like:

  • because the user wants to be warm
  • because the user is thirsty
  • because it’s a social activity
  • because it’s a habit

Those needs can be different for different users. We need to study which segments of users we have because maybe we want to focus in one of them:

  • commuters
  • friends
  • old ladies

And finally we have to study which business value we want to get from our product:

  • money
  • engagement

Needs, business value and segments

As you can see we’re not inventing any data here. We’re just collecting what our users want. We’re not relying on someone having a magic idea.

With this data we can construct a matrix. In one axis we can put the different segments we have, in another one we can put the different business value and in the different cells we can put how many insights we have for that pair. With that information we can see where we need more data.

So we now have lots of data and we want to develop the next killing feature of our app. How can we know which one we have to choose?

For each insight we have we need to specify which Business Value (PO), Need (UX researcher) and Segment (UX researcher and data analyst) that insight is for. With that, we can start doing a design brief. That means that we’re going to explore which options do we have, how the application will be and with the help of different types of testing decide if the epic worths the effor. This is obviously an iterative process. If the epic worths the effor when now start to explore it in more details. And here is where EventStorming comes to action. It can be a great tool to transition from this epic we want to implement, to the different stories we need to implement.

Design

Chris explained another way to go from the epic to the stories. For him, the inventor along with Dan North of the Given-When-Then, it’s quite natural to specify the stories in this format and he developed a technique that I really liked a lot.

Imagine that your developing an Imdb for music and you want to provide a feature for the segment fans where you can see the places that are important for a music star. Let’s then start with the most important outcome for you

1
2
3
Then displays the map
and my location
and the music star sites

What have the user to do to achieve this outcomes?

1
When I'm near a music star site

Which are the context of this action?

1
2
3
Given I'm a fan of a music star
and I'm GPS enabled
and there are sites for that music star

And there you are! You have your Given-When-Then backward developed. Two important addendums to this technique: - The context in a Given-When-Then can be mocked. That will be important when you want to develop a quick prototype of the feature. - The Given of your first Given-When-Then can be the Then of your previous feature. In this example, we can end up writing something like

1
2
3
Given blah blah blah
When blah blah blah
*Then I'm a fan of a music star*

And that is super cool and I think in some way links with the EventStorming idea, when that can be a domain event and we can think from that which are the options we have to produce that event.

Maybe for you this is something quite trivial and known, but for me was something exciting to discover. There is a well known process that helps us to discover what is the most valuable feature to deliver. I think that’s quite related to the work that Fatma and Nazli explained ThoughtWorks is doing in some projects. I will put the link tho their talk here.

This conversation with Chris was eye-opening for me. It opened a door into a world I didn’t know about it and that I find fascinating. To get deeper in this idea, I attended the workshop about Design Sprints from Silvia Calvet and Gastón Valle and I found it amazing. I really want to do this kind of things as soon as I can and study more about this.

Pattern matching is a powerful and amazing characteristic of F#. Actually, is so amazing that Microsoft is starting to port it to C#.

There are different kinds of pattern matching. In this post we’re going to take a look at a partial classification active pattern that takes an argument and returns a value.

As its name denotes, is a pattern that partially classificates what you match with it. That means that doesn’t try to define all possible options but just one. This is quite convenient when using an active pattern to define a business rule of your domain, because you can split the different cases in different partial active patterns making your code much more readable.

You will identify a partial active pattern because the definition looks something like this:

1
2
let (|WithRemainder|_|) divisor divident =
    // active pattern code
You can see between brackets the name of the classification followed by the wilcard name (_), the two of them between . Just after that you can see the two arguments that the function will take.

This kind of active pattern has to return an Option value. In our case, we are going to return the remainder, if any. So our active pattern will look like:

1
2
3
let (|WithRemainder|_|) divisor dividend =
    let remainder = dividend % divisor
    if remainder <> 0 then Some remainder else None

How we use it? Well, the first time you see this active pattern applied can seem a bit difficult to understand (at least it was for me! :P), but is not that difficult:

1
2
3
match 10 with
| WithRemainder 3 r -> printfn "The remainder is %d" r
| _ -> printfn "No remainder"

The difficult part here is to see that the value in the match sentence is passed as the last argument of the active pattern. For example, in our case 3 is the divisor (first argument), 10 is the dividend (second argument) and r is what the pattern returns inside the Option type, in this case the remainder (is not the Option type, is the value itself). Once you understand that, there will be no secrets for you to create and use this kind of active pattern!

When you have some unit tests developed using NUnit 2.x your FAKE script looks like something like this:

1
2
3
4
Target "RunUnitTests" (fun _ ->
    !! (testDir + "/*.Tests.dll")
    |> NUnit (fun p ->
          {p with ToolPath = "packages/NUnit.Runners/tools/"}) )

But NUnit3 works slightly different. Instead of having a single NUnit.Runners package, that package references some other packages (runner, extensions, etc). One of those packages is NUnit.ConsoleRunner that has the exe inside the tools folder.

But changing the ToolPath in the FAKE task is not enough. You should use the new NUnit3 action, which is inside the Fake.Testing module. So, we need to open the module and change the task definition:

1
2
3
4
5
6
let nunitRunnerPath = "packages/NUnit.ConsoleRunner/tools/nunit3-console.exe"

Target "RunUnitTests" (fun _ ->
    !! (testDir + "/*.Tests.dll")
    |> NUnit3 (fun p ->
        {p with ToolPath = nunitRunnerPath}) )

And hopefully when you run the FAKE script you’ll have something like this:

NUnit3 Results

In my current project we had a hard deadline: we had to go to public beta on August and finish the transition of all users to the new system by the end of August. When we knew those dates our first reaction was this one:

Deadinle!

Depending on the environment you work the reaction to these news are usually some combination of a lot of pressure from management, working a lot of hours, drop the quality of your code, hysteria, etc.

To be honest, we had some of that, but the main reaction was the right one: scope management. If you have a deadline, and assuming that hiring new people won’t ease your life, your last chance to success is to manage the scope of your project. Decide what is really really really important, what the users can’t live without and implement that. And nothing more. We conducted some workshops to do this work (the whole team, not only the product owner and business analyst) and the result was a reasonable product backlog to develop.

Apart from that, the team increased the commitment with the quality of his code. We increased the time doing pair programming, we did some mob programming for some difficult issues, we did lots of code reviews.

I’m not going to lie you and say that we were pleased to have such a hard deadline, but I think some of the consequences of having it have been really positive for the final product. Is far better to have an incomplete product that your users can use and give feedback than a super fancy product that nobody use.

A couple of weeks ago I saw these tweets (in Spanish):

As I respect enormously Modesto and Xabi’s opinion and I trust on the skills of a Carlos Ble’s apprentice, I decided to do the kata at home. And as I keep trying to learn F#, that would be the chosen language.

I recommend you to do the kata, is a very interesting one. In case you want to do it, please stop reading now and come back when you have finished it, as I’m going to explain how I solved it.

Spoiler alert

The kata starts pretty simple: you have to model a combat system between two characters of a RPG game. First you start with simple rules and in every iteration you add a slightly more complex one. At the end of the 4th iteration I ended up with a code like this:

As you can see, I have a list of rules that should be applied when attacking and a list of rules that should be applied when healing. I have a function to traverse a list of rules and apply them, and the rules are quite small and focused in one thing. I was quite happy with the design (remember, I’m learning Functional Programming, I can be totally wrong :) )

The real fun starts in the last iteration. In this iteration a new element of the game is introduced: a Thing. A Thing is an element that has health but nothing else. It can’t heal anyone, it doesn’t belong to any faction and it can’t attack. Is just something that everybody can attack.

Looks like a simple change but introduces quite a bit of complexity in the design. I decided to use a discriminated union to model a Player, so that a player can be either a Character of a Thing.

My first attempt to change the logic of the module was focused in two things: - Simplify the logic of the different rules, so that they just only need as a parameters the information they will use. - Put the logic around being a Thing or a Character in the main function

This solution ended up with a function like this:

Full code

As you can see, the code is a bit messy. It’s true that the rules now are a bit simpler and only receive as a parameter what they need, but on the other hand we have now three different types of rules that must be traversed in the main function.

So I decided to refactor my solution a bit. What I tried to accomplish was: - Move the logic around being a Thing or a Character to the rules. Now a rule is the responsible of knowing what to do in each case. - Simplify the logic of the main function. Now, it just differentiate about an Attack and a Heal, calls the same function to traverse the list of rules (different in each case), and applies the result in a different way.

Here’s the code of the main function:

And here’s the code of a couple of rules:

I prefer this approximation. I don’t have a nested pattern matching in the main function. I only have a list of rules for each case and the rules know what to do in each case. My concerns are: - What will happen if the types of players grow? Is there any way to generalise the types (i.e. a player that could be attacked, healed, etc)? - What will happen in the number of parameters of the rules grow? Is a smell that the design is not good enough? Should I introduce a parameter object (well, in F# maybe is a parameter record type :P )?

I’d love to hear your thoughts about the design :)