Asier's thoughts

Blogging about software development



I got to the conclusion that the successful delivery of software is all down to care.

If you have developers who care they will write clean code, with unit test and follow TDD approach. The code will be easy to change, enabling the business to make quick decisions against the market so they can beat their competitors.

If you have product owners (or project managers) who care they will try to bring the best features to their products. They will speak to developers and testers and define together the best possible solutions and refine their features in the process.

If you have testers who care they will try to understand the features that are being request to be developed. They will stablish conversations with business people and developers so they will know which tests to write in order to verify the product is working as expected.

If you have operations people who care they will enable their systems for easy deployments. They will talk with developers and give them the power to easily change their code in production while giving technical advise.

In general, if you have people who care they will try to do their best while looking for ways to improve.

If you are one of that many companies struggling with your software delivery my advise is simple: hire people who care! That would be the first step, after that everything will come together slowly.

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

Clean Code Development: Orange Grade

Now that I have finished with the principles from the Red grade I can move on and start with the next grade of the clean code development: the Orange grade.

The principles are:

  • Single Level of Abstraction
  • Single Responsibility Principle
  • Separation of Concerns
  • Source Code Conventions

And the practices:

  • Issue Tracking
  • Automate Tests
  • Eager Reading
  • Code Reviews

I will go through each of the principles during the next weeks and jump to the next grade when finished. I will define the practices of each grade when I come back again in my next iteration through the grades.

+ info at and here.

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!  😉




Beware of optimisation

In my short career as a developer I have heard many many times the word optimisation and I am already sick of it…

  • You have to optimise your code so it runs faster.
  • Do not use an ORM, just write SQL in your code. If  you use store procedures even better! You have to optimise!
  • We will add all of this extra attributes in our objects. We don’t need them right now, but we will do in the future. Is more effective doing it now that having to change the code in a later stage.
  • We need to create a caching system in our application so we optimise the times we access to the database.
  • etc.

At first you will think all of this is good. Why don’t we want to optimise? Optimisation is good, really. Makes our systems faster, better! Doesn’t it?

Well yes and no. We should be careful with optimisations, they add extra complexity to our systems, and we should aim for simplicity. Before optimising you should ask yourself: Do I really really really need that optimisation??

More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity.

W.A. Wulf

If you want to optimise check first the benefit you will get from it.  You shouldn’t be optimising without measuring.  Use a profiler and measure it. Is it still worth it? If yes, go for it.

In my case, I try to avoid optimisation as much as possible, do that decision as late as possible. Don’t  worry, when you really need it, you will optimise!

Rules of Optimization by MA Jackson:

Rule 1: Don’t do it.
Rule 2 (for experts only): Don’t do it yet.


KISS – Keep It Simple Stupid

Second principle in the red grade, Keep it simple stupid or KISS.

From wikipedia:

The KISS principle states that most systems work best if they are kept simple rather than made complex, therefore simplicity should be a key goal in design and unnecessary complexity should be avoided

Many times I have seen people overcomplicating things when it comes to software, as if complexity will make a system better. But it is just the opposite!

Complexity is the evil in software systems and ultimately a huge impediment in order to keep our code clean. We, as professional developers, have to avoid it at all cost. Keep everything as simple as possible. Build systems based in simplicity, with small classes and small methods, also avoid writing comments as much as possible – write a minimalistic code.

And don’t just focus in the code when it comes to the KISS principle. Do not add features to your software that you are not going to need, do the simplest work that could possibly work, design simple to use interfaces, beware of optimisationcreate the minimum documentation, and keep your processes simple following the agile/lean methodologies.

Simplistic software systems are easy to maintain, are easy to refactor and definitely easy to evolve. In this ever-changing world that we are living were markets, products, customers are changing constantly simplicity is a-must and a key to success.

As Leonardo Da Vinci once quoted and then became an Apple slogan in the 77

Simplicity is the ultimate sophistication

Also, as a personal advise do not embrace  simplicity just in software, embrace it in your everyday life! 🙂


DRY – Don’t Repeat Yourself

The first principle of the red grade is Don’t Repeat Yourself or DRY. It’s origin can be found in the Pragmatic Programmer, one of the most important books in the programming world.


DRY tackles code repetition and states that we should avoid it.

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Quite simple and obvious thing. However, not everybody follows this. The copy and paste is much easier than having to think how to avoid this duplication.

Much easier? well, at the moment.. But what about when you came back to that piece of code and whant to change something? You will have to make sure that you are making the change in every duplicated piece.. if the duplication has happened in more than a place this could became a maintenance nightmare. Also, this duplication it is just clutter in the code which makes in more difficult to read. And we spend most of time reading code.

So, if you want to write maintainable clean code DO NOT REPEAT YOURSELF!