Asier's thoughts

Blogging about software development

Leave a comment

Specification by example

Last week me and my colleague  Jorge went to Agilia conference in Brno, Czech Republic. The conference was on average good, but what we really enjoyed was the Specification by Example workshop we attended after the conference.

It was a 2-days course given by the great Gojko Adzic. He went through it with explanations of what Specification by Example is, how we should apply it at work and which are the benefits of it. We alternated that with several team exercises and many coffee breaks 🙂 We also learnt how to write good and bad specs. At the end of it he told us about the real software quality and even gave us an introduction to Impact mapping!


So what’s Specification by example?

Specification by example is a technique which brings together the requirements gathering and QA testing processes in the software development cycle. It is also knows as ATDD or even BDD, but I don’t really agree with the last terminology..

Basically it is a way of writing specifications collaboratively  which are then converted to automated  acceptance tests.

How does it work?

Testers, developers and business people will get together in one room and will write specifications for the new features that they want to implement. In order to do that they will get separated into different teams, get a white board each and write examples of how the system should be working after the new features have been implemented. Once all the teams are done they will get together and compare the examples, look for differences and agree in some common ones.

Spec in Gherkin format

Spec in Gherkin format

After the team workshop is over, testers will take those examples and automate them with a tool like cucumber or fitness. Developers will implement the features and will know they are finished when these tests pass. These tests will run against the actual system frequently. If tests got automated before the development work starts this is know as Acceptance Test Driven Development, the same as TDD but from a ‘higher’ point of view 🙂

It is not really necessary to do the whole team workshop, but it is the most effective way. However, sometimes it won’t be easy to get all those people at the same room and just bringing together one tester, one developer and somebody from business will do it – the three amigos way. At other occasions the team will be distributed, one person writing the spec and the another one or two reviewing it may work.

Which are the benefits?

The two main benefits brought by specification by example are having a single source of truth and getting a quicker feedback.

The examples are requirements and also tests. What is written in the requirements is automated as tests and run against the actual system. If a requirement changes the test will change and the system will have to, if we add a new requirement there will be a new test and the system will have to change to make it pass. Basically, what is specified in the requirements it is what the system does! No more requirements document and qa test that differ. The examples are the single source and we know they say the truth because they are automated and run against the system frequently. This is known as the Living documentation.

The good thing of bringing together business people, developers and testers is that we will spot things much earlier in the process. Instead of waiting to solve misunderstandings once the development work has been finished we can bring forward this feedback to the point were requirements are gathered. Handing over documents from Business Analyst to developers and then to testers is not the good way to do it, many times things will get lost and won’t be spotted till the testing phase or sometimes even production! Put everybody together before the development work starts and many communication issues will get solved in no time, rather than waiting till the end of the iteration.

Another key benefit of the workshops is that they will bring a better understanding of the actual system to everybody and will help modelling it. When writing the specs collaboratively everybody will get to a common language which then can be used when developing the system, documenting it or at any further discussions later on so there are no terminology misunderstandings – this is known as the Ubiquitous Language.


I kind of knew about specification by example before the course and we were already doing in it a certain way at work with the three amigos way, but not properly. I hadn’t heard about the team workshop and I find it quite interesting to be honest. I would like to try it. I just need to convince business people 🙂

As a feedback about the course I would say it was awesome! It was presented in a quite entertaining way. Challenging and fun team exercises in between engaging talks from Gojko with real life cases from his work as consultant. At the end we got a about 10-page document that summarizes everything. I am planning to get the book and learn more about it.

Maybe the one about Impact mapping too.. sounds quite interesting!



Leave a comment

The only way to go fast is to go well.

– Robert C. Martin

Uncle bob is a big advocate of writing high quality code or clean code as he likes to call it. He says the success of software projects are strongly related in their internal quality. The lower the quality of the code the more difficult will be to make changes to it.

Software projects with low quality will make delivery schedules to get postponed and thus big amounts of money got lost. This will create bigger pressure in the project making developers to go for the quick and dirty way. As a snowball effect quality will go down down down.. Every new change will make the code even worse and harder to make more changes in the future.

Therefore, for a successful delivery of a project quality is paramount. Every day developers will have to keep their code base clean and avoid the quick and dirty option. Even if management is pressuring them! Going dirty will never be quick at the end of the day. The dirty way will slow us down. It will be foolish. Thus, The only way to go fast is to go well.

Practices as unit testing, TDD, mercilessly refactoring, keeping the background cleaner than you found it and giving honest estimates will help in the matter. I like to keep my code clean, taking extra care. Small classes with small methods with the right names, etc.  It is not an easy task to be honest. Just practice and experience can teach you. Still I have much too learn!

Also I highly recommend reading the book Clean code by Robert C. Martin.

Clean code book

Good luck and keep that code clean! 🙂

Leave a comment

The rise of Javascript

In the last few years Javascript has become quite a popular thing and it looks like it is getting bigger and bigger day by day.


I’ve recently read JavaScript Patterns from Stoyan Stefanov and I can say that it is quite a good read. If you want to learn what Javascript really is, go for it!

I remember my first approach to this language about 10 years ago when I was learning the basics of the web. To be honest, I kind of hated it at that time. I thought it was a wrong version of java and too complicated to use – how wrong I was! I would use it for client side html manipulation, which it wasn’t easy at all at that time.. specially debugging it was quite hard! So I gave up.

Through the last years with jquery and all those libraries things have changed a lot. Programming javascript became easier and the language started showing up more and more in web browsers.  More js skills were demanded for software developer roles. So I decided to give it another go.

I liked more this time, but I wasn’t totally convinced till recently.

It’s been the last few months when I am really liking it. And enjoying it! 🙂 I started playing around with unit testing libraries like jasmine, watching some videos from Crockford and learning node.js and express.js. I can tell that really I didn’t know Javascript! And this have been more clear after I read the book from Stoyan Stefanov.

It’s kind of a change of mindset. I am coming from strongly typed class based languages like C# or Java. But Javascript is dynamic typed and prototyped based. I have already came across to dynamic languages with Ruby or PHP, but no having classes is a new thing for me.

I don’t think many developers really understand Javascript and because of that they will say it is a secondary language.. Well, I can say that they are wrong!

Javascript is getting more and more and more popular. A lot of client side applications are being written in javascript, there are a lot of libraries out there to do almost everything and now with node things are getting even better. Good proof of that is we are starting to see javascript showing up in the enterprise, paypal has moved from java to javascript! And we will be seeing it even more. There is even people talking that it will become the one language. Who knows, time will tell..

Leave a comment


Some years ago I went to university and did the computers engineering degree. I remember we had one of those subjects related with business management that you wouldn’t expect to have in such a degree. We learnt the basics of manufacturing processes. Among other things we went through things like mass production, Fordism, Taylorism and Lean manufacturing. Even if it was kind of interesting I thought all of that was pointless for a guy like me who wanted to learn just things about computers.  How wrong I was!!

Let me explain you why..

Toyota_logo 2

Lean manufacturing or just-in-time production is a manufacturing process developed by Toyota in the 80s. Focused on eliminating waste and adding value, lean brings an improvement to the models  based on mass production created at the beginning of the century.

These processes created by Ford and Taylor had as main goal to produce as much as possible – the more products we create the more money we make. So these processes were centred on splitting in little tasks the whole process of manufacturing a product and then trying to improve each single task as much as possible. Little improvements can make a big difference. If we can improve the whole production chain we can create products faster and cheaper than our competitors.

What Toyota realised is that producing as much as possible is not always the most efficient thing to do. Mass production creates big inventories for products with the purpose of creating a good availability of products for the customer.  The problem with this is that the storage of products has a cost, a cost of money and resources. This is know as waste. Also this products will have no value until they get to the customer.

So Toyota thought “What if we just create only the minimum quantity of products required for the customer needs?” “What if we could predict the customer needs and  deliver products just-in-time? We won’t need all that inventory!”. So Lean was born. Lean identifies different type of wastes in a manufacturing system and tries to eliminate them while adding more value to the processes – preserves value with less work.

This just-in-time production approach brings great flexibility and responsiveness to change. Which is basically what all these new software methodologies – a.k.a agile – try to tackle nowadays.

Based in iterative and incremental development agile methodologies aim to deliver software quick and often with a close customer collaboration and putting people first. The consequence of this are a shorter feedback and a bigger adaptiveness.  These methodologies are a significant shift from the previous waterfall models where everything is design up front with little or none response to change. Agile has been seen as the way to go in nowadays world where everything is constantly changing and almost every company tries to adapt it.


Lean has many similarities with agile. Mary Poppendieck and Tom Poppendieck saw this and wrote a book about it which I just read: Lean Software Development: An Agile Toolkit.  The book takes the lean manufacturing principles and adapts them to the software environment.  As I read it  I could see how everything I knew about lean manufacturing was fitting with the agile methodologies perfectly!

The funny thing about the whole thing is that I finished university without hearing a word about agile! Yes, don’t ask me why… I learnt agile by my own at my first jobs and reading books. One day, I bumped into lean software development and I thought “shit! This rings a bell..” and suddenly all my memories from the first years of uni came back to me! Everything started to fit together! 🙂

1 Comment

Favour composition over inheritance

The 4th principle from the red grade in the clean code development grade system says (from wikipedia):

Composition over inheritance (or Composite Reuse Principle) in object-oriented programming is a technique by which classes may achieve polymorphic behaviour and code reuse by containing other classes that implement the desired functionality instead of through inheritance.

Inheritance is used in object-oriented programming as a way to reuse code through different objects.  We can define parent-children object structures, so methods an variables are passed from the parents to their children – the code is inherited. This is a powerful mechanism to avoid code replication – to be DRY-, but it has its drawbacks.


The problem is that in a parent-children structure,  children are dependent of their parent. If a behaviour in a parent changes all its children’s behaviours will automatically change. Or if a new behaviour is added to the parent all the children will inherit that behaviour too. Sometimes this is not what we really want. Let’s see why.

I am going to use an example from the first chapter of the book head first design patterns.


In the example, the user wants to build an application which deals with different types of ducks. Every duck flies, swims, and quacks, so in order to reuse those behaviours a Duck super-type is created with the methods quack, swim and fly. Every duck in the system will inherit from the Duck class and therefore inherit those behaviours too.


The problem comes when a new type of duck is introduced into the system which is not supposed to fly: the RubberDuck. If we make this new type to inherit from Duck, we will make the rubber duck fly! That’s wrong.. But if we don’t use inheritance we will have to replicate the quack and swim methods! That’s not really DRY.. So what should we do??

The solution to this is to use composition for the code reuse instead of inheritance. Each of the behaviour that a duck could need -quack, swim, fly – will be separated into a new class –QuackBehaviour, SwimBehavour, FlyBehaviour. Then, each different duck type will use just the needed behaviours.

The code will look like this:

public abstract class Duck
 protected IFlyBehavior flyer;
 public virtual void DoFly()


public class MallarDuck
 public RubberDuck()
 flybehaviour = new DoesntFlyBehaviour();

public class RubberDuck
 public RubberDuck()
 flybehaviour = new DoesntFlyBehaviour();

public interface IFlyBehavior
 public void Fly();

public class FlyWtihWingsBehaviour: IFlyBehavior
 public void Fly()
 // Flying coe

public class DoesntFlyBehaviour: IFlyBehavior
 public void Fly()
 // Do nothing

The example in the book goes deeper and ends up using the Strategy Pattern. I recommend reading that first chapter and the rest of the book if interested. I quite like it, it does not just go about design patterns, but also about main oo principles and why these patterns exist. Also, the first chapter is free in amazon’s look inside or as a sample for the kindle!

In conclusion, inheritance it’s a good way of keeping our code clean and DRY, but it makes sub-classes coupled to their super-classes. Use composition instead  of inheritance if possible.

head_first_design_pattern - Copy

As it says in the book cover, do as Jim and cut down your inheritance!  😉