Asier's thoughts

Blogging about software development


Command returns true/false for success/error

I’ve seen this kind of pattern usually when working with web services.

Imaging the following piece of code:

public bool RunCommand()

    // .. Some logic ..

    return true; // success


Basically we have a method in a class that executes some logic, if this is successful it returns a true, if not a false. At first you would say this make sense, right?

It kind of reminds me the days when I was learning C 🙂

But this is just over-complicating things. Any client of this method will have to add a check.

if(RunCommand()) {
  // everything good

  // Show user success message

} else {

  // error!

  // show user something went wrong


Why not just assume that the method is going to be execute successfully? If not just throw and exception! Then just handle that exception. Simple!

Just adding the true/false return for success/error is basically re-implementing exceptions. Well, it’s even worse. Exceptions are explicit, they mean that something went wrong, they even have a custom error message. A boolean just means that.. a boolean: true or false, it’s open to interpretations. When we get a false it could mean anything, no error message, no custom exception.

Also returning values from command methods is a bad practice. You should have two kind of methods: querys that return values but don’t change anything in your system and commands that change something but return nothing! This is known as CQS or Command and Query Separation.

Leave a comment

Iterative waterfall

A new software project starts in your company. Budget has been approved and a (soft) deadline set.

Hey.. You are lucky this time! One of the managers “knows” about agile, he has read a book about Scrum. So we are going to do Agile this time! 🙂

The project manager gets renamed to product owner and starts writing stories for the whole project and adds them to the backlog.

Yes. All of them!  She already knows what we need for the whole project.

We will work in iterations. 2 weeks. Let’s call them sprints! 🙂

We will estimate the stories. We will check how many stories we are able to finish per sprint and based on that and the estimation we will know how many we will be able to do in the next sprint.

Let’s call this thing velocity. The velocity tells us how many stories we are able to get done per sprint based in the estimates.

Heyyy!! And look at that! If we have EVERYTHING we need in the backlog, and EVERYTHING estimated.. we can find out when we will finish the project and be able to deploy our code to production!!

OMG! We are sooo Agile! 🙂


Does this sound familiar??

The story I just told you it’s real. And I have seen it many times. And no, sorry to disappoint you, but that’s NOT agile, it’s iterative waterfall. It’s the same as doing waterfall but iteratively. All the requirements are set up front as user stories in the backlog and then work is done through sprints. This plan is rigid and bound to fail. Isn’t the goal of Agile to embrace change?

I have met so many people who think they work in an agile environment. Who think they are doing scrum because they work in iterations and know all those buzzwords: sprint, stand up, retrospective, velocity, etc. These people are just following the book but miss the whole picture. Following the practices because that’s how it has to be done.

Forget the practices and look deeper into what they mean. Which are the values? Why they exists? Why should I follow them? Should I follow them?

Is this what we do really agile?

Leave a comment

Lasagne Pattern

If you have a mess in your code where methods are being called from one place to another in such a way where is really difficult to follow the flow of the program execution this is known as Spaghetti code. Following with the Italian cuisine allegory, if you have too many layers of abstractions this is known as the Lasgane Pattern.lasagne-alla-bolognese-HEM1

I am just surprised how many times I have seen this anti-pattern in place! It’s typical in client server applications where programmers have learnt about the importance of a N-layer architecture and with a bit of cargo cult programming they end up overusing it.

In software, a n-layer architecture it’s a way of separating the code of an application in different components or modules. The code will be separated around different concerns. The typical separation of components is presentation, data access and business logic. If we are talking about a server-client application another component will be added to deal with the communication between both. If you draw an image with all the components like layers one above the other with the database at the bottom and the UI on top, it looks like a n layered or multi tier architecture. We can draw arrows from the presentation layer to the database to see the flow of the actions.


This is a good pattern and basically almost everybody follows it. The problem is when developers start adding layers just for the sake of adding layers! One layer more for the cache, another one for the application etc. Then you end up with loads of layers and many of them doing nothing, just delegating calls to the underlying layer.. To make it even worse different type of objects will be used between layers (Entities, DTOs, ViewModels, Ducks, Chickens..) with the extra work of having to map from one to another. If you add to this the need to unit test every single layer you will end up with a lot of work to do just to get a single record from the database!!

If you are not careful a misused n-layered architecture can bring a lot of unnecessary complexity. My advise is to use the least amount of layers possible (And store procedures are considered a layer). Don’t put layers just in case, software is cheap to change later on. Yes.. I know, architecture is not that easy too change, but still it can be done, try to deffer that decision as much as possible (maybe you can do some prototyping?) and be wary about layers.

Reference: I don’t know who came with the name, but I heard about this anti pattern first time in coding horror. Though there is called Baklava Code.