Basically, Danni McBride found this ad on facebook:

When you clicked on it, you were taken to Scott’s microsite prepared especially to amaze us from ThoughtWorks. The guy really knows TW and what we like… Very persuasive, brilliant.

Quickly, #dearscott on twitter was created.

I was quite surprised to see that people from Sydney office gathered to take this photo. It’s hard to get everyone in the office given most of the people are assigned to projects on the client site.

We haven’t interviewed Scott yet, but one thing we can say about him, he is creative and he managed to get his message through.

From that time on, whenever men wanted roasted pork they set a forest on fire.

The demand for roasted pork increased and it became a big business and it generated a lot of jobs.

There were men who worked at setting the woods on fire (firemen). There were weather consultancies with experts studying and advising other companies on the best weather conditions to achieve the best roasted pigs. There were also the wind specialists who could be trained and become Certified Anemotechnicians.

Due to the many bad points of "the system" complaints grew at an increasing rate, as the system expanded to involve more and more people. It was obvious that ”the system” should be drastically changed. Thus every year there were any number of conventions, and congresses, and a considerable amount of time and effort was spent on research to find a solution.

Those who were experts on the subject put down the failure of the system to:

• a lack of discipline on the part of the pigs, who would not stay where they should
• or to the inconstant nature of fire, which was hard to control
• or to the trees, which were too green to burn well

One day a fireman named John Commonsense said that the problem was really very simple and easily solved. Only four steps need to be followed:

• the chosen pig had to be killed
• cleaned
• placed in the proper utensil
• placed over the fire so that it would be cooked by the effect of the heat and not by the effect of the flames.

The director general of roasting himself came and asked Commonsense what he had to say about the problem, and after hearing the four point idea he said:

- "What you say is absolutely right–in theory, but it won’t work in practice. What would we do with our weather experts, for instance?"
- "I don’t know," answered John.
- “And what shall be done with the forests that are ready to be burned - forests of the right kind of trees needed to produce the right kind of fire, trees that have neither fruit, nor leaves enough for shade, so that they are good only for burning? What shall be done with them? Tell me!"
- "I don’t know."
- “What you must bring, are realistic solutions, methods to train better wind technicians. We have to improve what we have; we cannot ignore history. So bring me a plan. That is what we need. You are lacking in good judgement, Commonsense! Tell me, if your plan is adopted, what would I do with such experts as the president of the committee to study the integral use of the remnants of the ex-forests?"
"I’m really perplexed," said John.

Poor John Commonsense didn’t utter a word. Without so much as saying goodbye, stupefied with fright and puzzled by the barriers put in front of him, he went away and was never seen again.

It was never known where he went. That is why it is often said that when it comes to reforming the system, Commonsense is missing.

This is an adapted version of the original Fable of the Roasted Pigs.

Trevor, our CEO came to cut the ribbon. We had a Declaration of Independency from Sydney and Melbourne offices and at the restaurant I had snails for the first time, with Romain’s and Danni’s support

I’m still based in Sydney, but assigned to a project in Brisbane for around 3 months. I’m pretty happy with it, especially because of the great people we have here.

Go Brisbane!!! Thanks Danni and Super Dooper Dan Gower for the help setting up the office.

Photos by Danni McBride

One interesting metaphor in the book mentions that if we want to change one’s behaviour, or if we want them to agree with us on some subject which is different from their current beliefs, it is like riding a running horse… Basically if you try to jump on the horse and at the same time steer him towards another direction, it’s very likely that you will fall… However, if you jump on the horse and ride towards the same direction that the horse is going for some time and slowly steer him towards the direction you want him to go, then it is more likely that you will get some success.

Eventually you and the horse will be going towards a direction which is neither the original horse’s nor the one you had in mind when jumped on it… Both will learn from each other what’s the best way to go.

Photos from here and here

One of the big challenges was to make sure that the business and the technical people shared the same domain Ubiquitous Language. To ensure that, we started using JBehave to define the acceptance criteria of the stories. Half way through, there was a big change which required many changes in the scenarios…

Some issues that we found:

• The scenarios are text files and extremely hard to refactor.
• We had to change the text files (scenarios) and the Java files and keep them in sync
• Too much duplication
• When writing the scenarios we had no such thing as auto completion
• When running the scenarios, we could not run 1 scenario at at time, but the whole file

The solution was to abstract our own code with a DSL layer and use it for documentation purposes. Initially we called this JMisbehave because the initial intent was to generate a read only version of the code that we could show to non-technical people and agree on acceptance criteria, as well as keep an executable documentation of the application. Code Humaniser was another suggested name…

Eventually we realised that the code itself was sufficient and we ended up not using the code that generated the read only version of it. Nevertheless it’s still useful in many environments. Many times we showed the code to non-technical people and they were quite delighted to see how straight forward it was to read and to understand. Moreover, it was expressing the Language of the Business. An interesting thing is that our colleague Dan North, who wrote JBehave, came to our project one day to facilitate a retrospective and we told him the whole story. He quite liked what we had done and was quite complimentary about the fact that we had understood the concept of DDD and BDD, and the fact that it’s not about the tools. It was actually his recommendation to use the_underscore_notation instead of theCamelCaseNotation, we had some discussions about that, but that will be described on another post.

Behind the Scenes - The Scenario Code DSL Implementation

James Barritt saw another post of mine with some of our Scenarios Code DSL examples and suggested that I wrote a post explaining what was happening “behind the scenes”.  Here is a high level diagram of how we separated the layers:

Some code:

Scenarios Code

public class Location_Scenario extends BaseScenario {
  public void should_default_risk_address_when_insured_address_is_valid_for_risk() {
    given(the_broker. has_started_a_home_quote());
    when(the_broker. selects_a_valid_location_for_risk_address());
    then(the_policy.has_home_risk_location_and_risk_address_as_same());
  }
}

public class BaseScenario {
  protected Broker the_broker;
  protected Policy the_policy;
  (...)

  protected <T extends DSL> T given(T dsl) {
    return dsl;
  }

  protected <T extends DSL> T when(T dsl) {
    return dsl;
  }

  protected <T extends DSL> T then(T dsl) {
    return dsl;
  }

  protected <T extends DSL> T and(T dsl) {
    return dsl;
  }

}

DSL Code

public class Broker extends DSL {
  public FieldEnterer enters;
  public Policy the_policy;

  public Broker blah() {
     // call implemenation
    return this;
  }
}

public class Policy extends DSL {
  public FieldEnterer enters;
  (...)
  public Policy blah() {
     // call implemenation
    return this;
  }
}

This was a project with lots of people coming in and out all the time and every time someone new would join, the time taken to understand the code and relate it to the business terminology was extremely reduced by the way our tests were written.
You can do the same on your project, write your tests using the language of the business.

“An anti-pattern is a pattern that may be commonly used but is ineffective and/or counterproductive in practice” http://en.wikipedia.org/wiki/Anti-pattern

As a first step, let’s describe TTDD – Tautological Test Driven Development as an anti-pattern of TDD (TestDrivenDevelopment). In fact TTDD is a big enemy of the combination BDD (BehaviourDrivenDesign) and TDD.

I still have the vivid memory of the day that I was pairing with Dave Coombes and he mentioned that one of the tests I had written was tautological.

Tautological:
- needless, redundant repetition of an idea
- repetition of same sense in different words;
- the phrase “a beginner who has just started” is tautological

I did not quite understand at first why the test was tautological, i.e. needless, redundant.
As a perfect leader and coach that Dave is, he helped me rewrite the test in a different way and that was when I finally understood what he had meant by that.

Example

The example below is simplified version of the one that Dave and I were using at the time.
In this example, we want to test the class CarRepository that interacts with 2 collaborators as shown below:

In order for CarRepository to retrieve all the cars from CarService it needs a ServiceHeader that is provided by ServiceHeaderFactory. For the purposes of this example, I’ll show the implementation of CarRepository:

public class CarRepository {
  private ServiceHeaderFactory serviceHeaderFactory;
  private CarService carService;

  public CarRepository(ServiceHeaderFactory serviceHeaderFactory,
                    CarService carService) {
    this.serviceHeaderFactory = serviceHeaderFactory;
    this.carService = carService;
  }
  public Cars findAll() {
    ServiceHeader serviceHeader = serviceHeaderFactory.create();
    return carService.findAll(serviceHeader);
  }
}

Tautological Test

The test below is similar to the one I wrote that we described as tautological:

@Test
public void shouldRetrieveCarsFromCarServiceUsingTheRightServiceHeader() throws Exception {
  // GIVEN
  ServiceHeader serviceHeader = new ServiceHeader();
  ServiceHeaderFactory serviceHeaderFactoryMock = mock(ServiceHeaderFactory.class);
  when(serviceHeaderFactoryMock.create()).thenReturn(serviceHeader);
  CarService carServiceMock = mock(CarService.class);
  CarRepository carRepository = new CarRepository(serviceHeaderFactoryMock, carServiceMock);

  // WHEN
  carRepository.findAll();

  // THEN
  verify(carServiceMock).findAll(serviceHeader);
}

Why is this test called Tautological?

One of the definitions of a tautology is: “repetition of same sense in different words”

If you look carefully at these 2 lines of implementation and 2 lines of test:

Test

• when(serviceHeaderFactoryMock.create()).thenReturn(serviceHeader);
• verify(carServiceMock).findAll(serviceHeader);

Implementation

• ServiceHeader serviceHeader = serviceHeaderFactory.create();
• return carService.findAll(serviceHeader);

They are almost “equivalent”. When we write tests this way, most of the time if the implementation changes, we end up changing the expectations of the test as well and yeah, the tests pass automagically. But without knowing much about its behaviour. These tests are a mirror of the implementation, therefore tautological.

The test below verifies the same class CarRepository, but as a black box test, i.e. it does not test the interactions, but the output of the repository. Look at the assertion.

@Test
public void shouldBeAbleToRetrieveCars() throws Exception {
  // GIVEN
  Cars carsFromService = new Cars(new Car("Ferrari"), new Car("Porsche"));
  CarRepository carRepository = givenARepositoryAttachedToACarServiceWithCars(carsFromService);

  // WHEN
  Cars carsFromRepository = carRepository.findAll();

  // THEN
  Assert.assertEquals(carsFromService, carsFromRepository);
}

private CarRepository givenARepositoryAttachedToACarServiceWithCars(Cars carsFromService) {
  ServiceHeader serviceHeader = new ServiceHeader();
  ServiceHeaderFactory serviceHeaderFactoryMock = mock(ServiceHeaderFactory.class);
  when(serviceHeaderFactoryMock.create()).thenReturn(serviceHeader);
  CarService carServiceMock = mock(CarService.class);
  when(carServiceMock.findAll(serviceHeader)).thenReturn(carsFromService);
  CarRepository carRepository = new CarRepository(serviceHeaderFactoryMock, carServiceMock);
  return carRepository;
}

There is still a big effort to setup the mocks and inject them into the repository. This has been extracted to the method givenARepositoryAttachedToACarServiceWithCars. However, all these mock setups make it harder to understand the intent of the test, the responsibility of the class that we are trying to test. When this happens I usually tend to use stubs instead of mocks. Here is the same version of the tests, but using Stubs:

@Test
public void shouldBeAbleToRetrieveCars() throws Exception {
  // GIVEN
  Cars carsFromService = new Cars(new Car("Ferrari"), new Car("Porsche"));
  CarRepository carRepository = givenARepositoryAttachedToACarServiceWithCars(carsFromService);

  // WHEN
  Cars carsFromRepository = carRepository.findAll();

  // THEN
  Assert.assertEquals(carsFromService, carsFromRepository);
}

private CarRepository givenARepositoryAttachedToACarServiceWithCars(Cars carsFromService) {
  ServiceHeaderFactory serviceHeaderFactory = new ServiceHeaderFactoryStub();
  CarService carService = new CarServiceStub(carsFromService);
  CarRepository carRepository = new CarRepository(serviceHeaderFactory, carService);
  return carRepository;
}

It is not a rule, but I find that tautological tests have more mock setup. When we start to think about the collaborators as stubs, the tests become more behavioural.

What are the common characteristics of a Tautological Test?

• Asserts more interactions with collaborators than the outputs;
• It doesn’t really test the behaviour of the class, but only its implementation
• The test is too white box
• Too much mock setup deviates the intent of the test
• Adding a new feature or changing an existing one requires changing mock expectations

The game was Sydney Swans vs Fremantle. Of course we were supporting Sydney’s team Swans… But they lost… Even though the game was in Sydney and the stadium was 99% red and supporting them.

It was a great experience going to the SCG and catching up with some of my colleagues. These SSC events are perfect!

“An avatar is a computer user’s representation of himself/herself or alter ego, as a two-dimensional icon (picture).

http://en.wikipedia.org/wiki/Avatar_(computing)

Usually on our agile projects, we like to put up walls with big visible charts and walls where we, and other stakeholders, can see what’s happening. One of the most commonly used types of wall is a Story Wall, where one of the messages that we try to convey is who is working on what…

One of the ways of doing this is to stick the name or a photo of the person (or pair) who is working on a particular story. One of my life and work philosophies is that a hint of fun in almost everything very seldom hurts, on the other hand it brings a new and better atmosphere to the environment. So why not put a little bit of fun on the story wall?

My current team:

Nigel Fernandes had a goatee very similar to Ali G’s.

Prabin Deka has been using a scarf indoor, which reminded us a little bit of the posh Jude Law.

Ken Friesen is, obviously, Barbie’s husband.

And why is this Fabio supermodel so famous? I get that all the time… Damn it.

Try to be creative and come up with your own Avatar Selection Criteria… Phillip told once that he likes to Google for images with the person’s name and pick one from the first page… That’s a good one as well.

Anyway, the rule is to have a bit of fun.

Oh, I almost forgot the best Avatar on our project… Luke Stubbles got his name misspelled as Stubbies… And here is his photo.

Juliano Bersano, Benjamin Barnard, Pei Ren Tan, Shelley Beeston, Duana Stanley, Charlotte Chang and me!

Our captain Juliano Bersano described the games pretty well:

“It was indeed a pretty fun Saturday, with two losses followed by two wins, Scrum Attack does have an issue with getting points in the first iterations, then our velocity goes up. Next time we’re starting with two friendlies at 6am and then it’s guaranteed we will be through!”

Thanks everyone, it was a great Saturday. Let’s do it again.

All photos are here.