At the last TW TeamHug, I did a talk on Persuasion. It’s a summary of the two books I read recently: Predictably Irrational and Yes! 50 Secrets from the science of persuasion.
Just got back from an amazing weekend at the TW TeamHug. An event that happens twice a year and gathers people from all the offices in Australia plus some people from overseas. It was a record in Australia, around 150 people attended.
Talks, party, great view, games, drinks… One of the highlights was a the photo booth during the wild west party night. Even Fowler went into the booth 
I had some people asking me what is this whole #dearscott all about…
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.
Once upon a time, a forest where some pigs lived, caught on fire and all the pigs were roasted. People, who at that time were in the habit of eating raw meat only, tasted the roasted pigs and found them delicious.
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:
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 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.
A ThoughtWorks office in Brisbane was officially opened last week. We had already had an office in Brisbane, but it’s been closed and now we reopened it.
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
I just finished the book Yes! 50 Secrets from the Science of Persuasion, in fact I finished listening to it I have been using Audible to download some audio books, it’s really good actually.
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.
My previous project was distributed across cities and we had almost 30 people involved. Communication and the understanding of what needs to be done are crucial for the success of the project.
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 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.
One of the advantages of being a consultant is getting to see different environments and being able to visualise and identify patterns and anti-patterns.
“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
Implementation
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?
ThoughtWorks Sydney Social Club (SSC) once again organised a very interesting event. We went to an AFL game at the Sydney Cricket Ground (SCG).
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!
