Interview on QCon: BDD, Cucumber and Hexagonal Architectures

I was interviewed recently by QCon’s Peter Bell about various subjects dear to my heart: BDD, Cucumber, Relish and hexagonal architectures.

Click here to watch the video

Agile / Lean Software Development
BDD
Hexagonal Rails
Relish

Comments (0)

Permalink

Thinking outside the shu box

I just got back from the fantastic Lean Agile Scotland conference, where I spoke about why agile fails. I’ve been doing a lot of travelling this year since The Cucumber Book came out, consulting and training different companies in BDD. A pattern I keep seeing are companies who adopted agile a few years ago but have hit a glass ceiling. This talk was a chance for me to reflect on why that happens.

One point I made in the talk was about cargo cults. The term ‘cargo cult agile’ is used to laugh at teams who go through the same ceremonies – daily stand-up meetings, planning poker meetings, story points, velocity etc. – yet in some very fundamental ways, they just don’t seem to be succeeding the same way as organisations who get it. I see this frequently, but I don’t think it’s particularly funny. I think it’s a sad waste of human potential.

I’m curious to understand why it happens.

There are various models for how we learn things, and one of my favourites is Shu-Ha-Ri. This model comes from Japanese martial arts and says that in order to really master something, we need to progress through three stages. The first stage, shu, is about learning the basics. Here’s a quote from Aikido master Seishiro Endo:

In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forbearers created. We remain faithful to the forms with no deviation.

That’s shu: absorbing the basic mechanics by repetition, without really understanding why.

The next stage is ha:

In the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded.

Imagine that? Broken and discarded! This is the point where we start to ask why; where we start to understand the value of the practices we’ve been using and have enough experience to make decisions about when they’re actually valuable, and when they could be getting in our way.

The final stage, ri is transcendence:

Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws.

I think that sounds like fun.

Anyway, my point is that cargo-culting is just what happens when your team is stuck in the shu stage. If you’ve been on some basic agile training, you might have been led to believe that’s all there is too it; unless you’re aware that the other stages of learning exist, how could you aspire to reach them?

This morning I was asked a great question about the talk: How would I help a team that’s stuck in a cargo cult shu learning stage? I felt like it deserved a blog post, and that’s why we’re here.

My first step with that team is to understand how well they’d really learned the basics. Have the team been given enough support to really get to grips with the tougher agile practices like retrospectives, TDD, or pair programming? What problems are they suffering from and how can they be traced back to core agile practices that the team need more expertise in?

Then it’s time to help them learn and practice those basic techniques. Coding dojos are a great way to practice TDD in a fun environment, for example. Coaching willing members of the team how to facilitate effective retrospectives and helping make sure that actions coming out of those retrospectives are followed up helps to start building the culture of empowerment the team need to become confident enough to move beyond the shu learning stage.

It’s also important to have conversations with management to ensure that the team are being given the space to learn. I often see teams who are driven so hard by the demand to deliver features that they simply don’t have the time to invest in self-improvement. Once a product owner is made aware of this situation, and the benefits of having a higher-functioning team, they’re usually keen to make this investment.

Agile / Lean Software Development

Comments (1)

Permalink

Speaking at Lean Agile Scotland 2012

The Lean Agile Scotland conference is shaping up to be a really great event. I’ll be speaking about why agile fails, drawing on my experience coaching numerous software teams and organisations. I’ll highlighting the reasons why so many companies fail to reap the benefits enjoyed by the early adopters of agile and give you some insights into how to make your agile adoption a success.

We’ve also got some other great spakers like David Anderson, Liz Keogh, Karl Scotland, Clarke Ching and Gojko Adzic, to name just a few. Book your ticket now!

Lean Agile Scotland Speaker

Uncategorized

Comments (0)

Permalink

Triangulating from GOOS – Great books on Object Oriented Design

A few weeks ago I asked on GOOS the mailing list about some other books that teach the same style of design.

I’ve just put together a big order for the juiciest looking ones. Here they are:

  • Concurrency: State Models and Java Programs by Jeff Magee
  • Object Design: Roles, Responsibilities and Collaborations by Rebecca Wirfs-Brock
  • Object Thinking by David West
  • Object-oriented Design Heuristics by Arthur J. Riel
  • Object-Oriented Programming by Peter Coad

Would you add any to this list?

Agile / Lean Software Development
Hexagonal Rails

Comments (7)

Permalink

Public BDD Training (London, October)

So far all of my BDD training has been done in-house as private courses for companies. That’s about to change.

On October 8th – 11th Chris Parsons and I will be running four one-day training workshops in London focussed on BDD and specification by example. These are the same courses we’ve been successfully running in-house for companies like the BBC, Burberry, and Virgin Atlantic.

There are a range of workshops for everyone involved in software development:

  • experienced testers who want to automate their manual tests
  • product owners and business analysts who want to communicate their requirements more effectively
  • project managers who want less defects and more velocity
  • experienced programmers who want to become better testers
  • experienced Cucumber users who need help with advanced issues like brittle and slow tests

We’re offering a 20% discount to anyone booking before the 1st August. Just use the promotion code super-early-birdy when booking.

So, what are you waiting for?

Agile / Lean Software Development
BDD
Ruby Programming

Comments (1)

Permalink

Matt vs NYC

New York is one of my favourite cities in the world. I’m extremely fortunate to be able to spend a whole week there next week. I’ll be mostly hanging out at QCon:

I’m also going to run a couple of sessions at General Assembly on Thursday evening. If you can’t afford the time or ticket price for QCon, this might be a good option to come along and hear some of my ideas:

  • At 6pm on Thursday I’ll be doing an intro-level talk on BDD. It’s aimed at business people, development managers etc who want to get an idea of the benefits of specification by example and a wider BDD process. Sign up here.
  • at 8pm on Thursday I’ll be doing my ‘BDD as if you meant it’ demonstration, using the example from the middle section of The Cucumber Book. If you’re already using Cucumber, this should give you some fresh perspective and insights about how to use it most effectively. Sign up here.

Finally, I’m honoured to be spending Saturday on the bill with some amazing people at the Gotham Ruby Conference. I’m going to be speaking about hexagonal rails. I’m excited and nervous about this talk, as I feel like I’m still discovering so much about this topic all the time.

As well as all this geekery, I’d love to get some proper culture while I’m in town. Are there any locals who would like to show me around?

Agile / Lean Software Development
BDD
Hexagonal Rails
Ruby Programming

Comments (1)

Permalink

Hexagonal Rails: Objects, Values and Hexagons

This is the second post in a series about my experience of applying a GOOS-style hexagonal architecture to a Ruby on Rails application. In the first post, I talked about why the idiomatic, connected, style of Rails architecture might have advantages in the short term, but that I want a more modular architecture to make it habitable for the long term.

In this post, I’ll explain a couple of the fundamental concepts that will be used in the rest of the series, which should give you some new ideas to think about as you’re working on your own Rails applications. We’ll talk about the tell, don’t ask style of object communication, and about the difference between objects and values. Let’s start by explaining what that funny term hexagonal architecture actually means.

So what is a hexagonal architecture?

The fundamental idea behind this style of architecture is to isolate the core domain of your program—the bit that defines its unique and interesting behaviour—from the technical infrastructure that enables it to talk to the outside world. Technical infrastructure means things like databases, file systems, user interfaces, web services and message queues.

We can visualise it as two hexagons, one inside the other, as in the diagram below. The inner hexagon contains our core business logic. It doesn’t know or care anything about the details of how it will communicate with the outside world, but it exposes ports where we can plug in adapters that fulfil that role. The adapters sit in the outer hexagon, and translate between our core domain and the technology-specific domain of a particular piece of infrastructure.

Hexagonal Architecture Sketch

That’s it, nothing fancy. The word hexagon isn’t actually really very important but I like to think it as a metaphor for the modular, pluggable nature of this architecture. It’s catchier than ports and adapters, too.

Keeping this separation between the inner and outer hexagons, between the core behaviour and infrastructure details of our program, gives us a few advantages:

  1. Our code is easier to understand. When we’re working in the inner hexagon, all the language and concepts we see are related to our core domain, without the distraction of the technical realities of connecting it to the real world. When we’re working in the outer hexagon, we can concentrate on the job of mapping core domain events and data onto the domain of the technical infrastructure that we’re writing an adapter for, without the distraction of business logic.

  2. We can easily replace pieces of infrastructure, such as swapping out a relational database for a key-value store, or using an in-memory database for fast acceptance testing, without modifying the core domain at all.

  3. Our tests can run fast. The code in the core domain does not depend on Rails or any other large external libraries, so its tests are lightning quick. Once we start to recognise core domain logic and push it inside the inner hexagon, more and more of our tests are running against plain old Ruby objects that are quick to instantiate. We have separate tests for our adapters that ensure they integrate with their respective technology, but we don’t need to run them as often as we used to. We only need to run those slow tests when the adapter needs to change, and because our business logic has moved into the core domain, that’s not very often.

There are apparent costs too. As I’ve moved the Relish codebase towards a more hexagonal style, I’ve noticed that there’s more code appearing. However, each piece of code is simpler to understand, and the pieces are much less coupled together, giving me flexibility for the future.

For me, probably the biggest factor in achieving this flexibility has been finally understanding an object-oriented design axiom I’ve been hearing for a long time: that objects should communicate by telling each other things, rather than asking each other questions.

Tell, don’t ask

Your Rails application most likely has a problem with procedural code. When I talk about a procedural style of programming, I am talking about this kind of thing:

class PublishersController < ApplicationController
  def create
    @publisher = Publisher.new(params[:publisher])
    @publisher.creator_user = current_user
 
    if @publisher.save
      current_user.add_membership(@publisher)
      redirect_to publisher_collaborators_path(@publisher),
        :notice => 'Publisher created successfully. You can now add collaborators.'
    else
      render :index
    end
  end
end

This is a fairly typical Rails controller action method. We can read this code and quite easily understand what is going to happen when it runs. This is the advantage of a procedural style – it reads like a story. The problem with this style really hits us when we want to change the behaviour.

Imagine we want to add an activity feed to our application, so that as a side-effect of successfully creating a new publisher, we want to post a message to the user’s activity feed. The way things stand, we’d probably be inclined to squeeze another line into the top branch of that if statement:

...
if @publisher.save
  current_user.add_membership(@publisher)
  current_user.feed_entries.create! content: "Created a new publisher #{publisher.name}."
  redirect_to publisher_collaborators_path(@publisher),
    :notice => 'Publisher created successfully. You can now add collaborators.'
else
...

Over time, as more and more behaviour is added to the application, this is only heading in the direction of chaos and ugliness. A more object-oriented design would allow us to plug in the extra activity feed behaviour without modifying this code at all, and it’s the tell-don’t-ask principle that will guide us into producing that kind of code.

We don’t have space for an example here, but we’ll see plenty of them as the series unfolds.

Your domain is in the protocols

Let’s examine that controller action again, looking in detail at the messages passing between the different objects in the scenario where the publisher is saved successfully. All in all, there are six different actors in this little scene: the Controller, the Publisher class, the new Publisher instance, the current User instance, the user’s Feed Entries collection, and Rails itself. Let’s imagine this method as a conversation between them:

Controller: Dear Publisher class, please may I have a new instance using these parameters? [Query]

Publisher Class: Certainly, here you are. [Query Response]

Controller: Publisher instance, this User instance is your creator_user! [Command]

Controller: Publisher instance, attempt to persist yourself! [Command]

Controller: Hey Publisher instance, did the attempt to persist yourself succeed? [Query]

Publisher instance: Thanks for asking! Yes, it went perfectly. [Query response]

Controller: User instance, grant yourself membership of this publisher instance! [Command]

Controller: User instance, can I see your feed entries collection please? [Query]

User instance: Oh alright then, here it is. [Query response]

Controller: Feed entries collection, create and persist a new entry with these parameters! [Command]

Controller: Rails, redirect to the following path, and show this message to the user! [Command]

In total, there are eleven different messages passing between the six different objects in play as this method runs. Of these, five messages are commands, and the other six are queries or their responses. We’re not even counting the potential for the call to feed_entries.create! to raise exceptions – we’ll talk about that some other time.

A revelation for me as I re-read GOOS recently was this: Your domain model is not in the classes you create in your source code, but in the messages that the objects pass to one another when they communicate at runtime.

In other words, the structure of these conversations—the protocols—is what’s most interesting about your application. The simpler you can keep these protocols, the easier your code will be to change in the future. Code that involves queries is inevitably more complex, because the code asking the question needs to then act upon the answer. Using a tell, don’t ask style encourages us to push that action off into other objects. Smaller, more re-usable objects.

So is there ever a valid case for using queries? There is, and that’s when the object is a value.

Objects and values

The authors of the GOOS book distinguish between just two different categories of class in an object-oriented program: objects, and values. As Rails programmers, we can find these two categories confusing because many of the objects we’re used to dealing with, particularly ActiveRecord::Base subclasses, fit into both categories. Nevertheless, I’ve found these two labels extremely useful in helping me think about how I structure my own core domain code.

Objects are the things that get work done. They may carry state, but they don’t expose it. They receive messages from collaborating objects, and make decisions about what messages to send to their collaborators.

Values carry state. They’re immutable: once created, they can’t be changed. Values have query methods that either return component parts of their state, or the results of calculations on that state.

So I’ve explained that a hexagonal architecture involves separating the code that allows your application to talk to the outside world, from the code that is the application itself. I’ve talked about how, when designing that code, it’s important to think about the protocols between the objects, and I’ve talked about the difference between objects and values.

I realise that these first two posts have been fairly abstract and theoretical, but I really felt I needed to put down some terminology before we could continue with the story. In the next post we’ll get much more practical and look at a pattern for applying tell-don’t-ask in my Rails controllers which I’m calling passive controller.

Hexagonal Rails

Comments (6)

Permalink

A vision for Cucumber 2.0

At last month’s CukeUp conference, I held a panel discussion between Aslak Hellesoy, Julien Biezemans, Oriol Gual and Jonas Nicklas. I chose these panelists because each of them has written a variation on the original Ruby Cucumber, and I wanted to try to pull these ideas together into a vision for Cucumber 2.0.

This post is a record of that conversation.

Why do we need a new Cucumber?

The current version of Cucumber has been around since 2008, and as Jonas has previously explained the code isn’t much fun to hack on. It’s quite bloated with features, some of which were added as experiments and maybe aren’t used by most users. Carrying this cruft around is holding us back from adding new features that we do want.

Also, the current mechanism for mapping from steps to Ruby code is pretty basic, and doesn’t really encourage the good practices we’ve learned as a community about organising your test code.

What is your vision?

I asked each of the participants what they’d learned from their fork of Cucumber, and what they’d like to see in a new version of Cucumber.

Aslak made three points:

  • It should be possible to use Cucumber as a library, so that other tools can be built on top of it as well as the command-line interface.
  • The way steps are defined in Cucumber-JVM, by simply annotating existing methods, allows you to focus on keeping your test code well organised. We should steal this idea for Cucumber-Ruby.
  • There should be a collaborative web UI for writing Cucumber scenarios with non-technical stakeholders.

Julien added:

  • Integrating the Cucumber-HTML project, which is essentially a web-based client for Cucumber, would be awesome.
  • It would be nice to use the Cucumber-TCK, which is growing into a standard set of specs for any Cucumber implementation.
  • He hasn’t implemented calling steps from step defs in Cucumber-JS, and he’s not sure he wants to.
  • Parallel execution – can we make this possible?

Oriol echoed Aslak’s thoughts about keeping test code better organised: Spinach uses one class per feature, and is generally more object-oriented unlike Cucumber-Ruby’s flat anonymous blocks for step definitions.

Jonas said his goal for Turnip was mainly simplification:

  • He thinks that the reason some people had started to abandon Cucumber was to do with it being perceived as complex.
  • Jumping from plain english steps to Regexps is jarring, and too big a leap in abstraction. 98% of the time you don’t need regular expressions anyway. Turnip uses the concept of placeholders in strings instead to capture arguments.
  • Using RSpec as the runner for Turnip hasn’t worked out so well.

What features should we remove?

It’s always fun making a ‘not’ list, so we brainstormed the current Cucumber features we’d like to kill in a 2.0 release:

Cucumber: Features to Kill

In case you can’t read my scrawl, here’s that list again:

  • Wire protocol
  • Calling steps from step defs
  • Tables (we’re talking about scenario outlines here)
  • DRB / Spork
  • World having everything mixed in, all the time
  • Cucumber.yml
  • Given / When / Then being regarded as the same by Cucumber

As you can see, we got the audience to come up and vote after the session. It looks like nested steps are living on borrowed time!

My view is that with a well-designed core, many of these features can still exist but as plug-ins, thereby allowing people who need them to continue to use them, but without the maintenance burden on the core team.

So what’s next?

Well, I think I have a pretty clear vision for what Cucumber 2.0 would look like. I’d like to start with a simple core library that has no GUI component at all, but can pass the TCK tests. Then we can start building tools around that core, like a console runner, and a websocket server for running cukes from a javascript browser app. I’m personally really excited about where that last idea could lead.

What I’m short on is time. Would it be crazy to ask if there are any companies who would consider sponsoring this project? I can’t imagine a better way to spend the summer than hacking out a brand new shiny Cucumber!

Update: Thanks for the comments, but I don’t find they make a great medium for discussion so I don’t tend to reply to them. If you’d like to discuss this post, please chip in on these threads on the cukes google group.

Agile / Lean Software Development
BDD
Relish
Ruby Programming

Comments (16)

Permalink

Bootstrapd – a conference for self-funded startups

I’ve been trying to bootstrap a product for the last year or so; I’ve also got several friends who are either already doing it, or have recognised that it’s a better way to make a living than consulting / contracting for a daily rate. I want to get everyone together so we can swap ideas and experiences, and inspire each other.

So, together with Steve Tooke of Heavies, I’m organising a conference.

It’s a simple, not-for-profit event, to be held in Edinburgh on Wednesday 27th June. More details here: http://bootstrapd.com

Agile / Lean Software Development
Relish

Comments (0)

Permalink

Interviewed by RubySource

Last week I had a great chat with Pat Shaughnessy about The Cucumber Book which has been published as an interview on RubySource. Pat really managed to get to the heart of my opinions about how to use Cucumber effectively, so if you’re too busy to read the book, this will give you a good summary of my latest thinking on topics such as:

  • - why Cucumber is pointless unless you involve the whole team
  • - imperative vs declarative style, and why it matters
  • - testing domain objects directly from Cucumber
If you’re using Cucumber or SpecFlow day to day, or considering them and wondering what benefits you’ll get, I think this interview is worth a read.

Agile / Lean Software Development
BDD
Relish

Comments (1)

Permalink