Yesterday I had a very interesting conversation with Keir (one of my students at MakersAcademy) during our lunch break.

We talked about the relationship between cooking and software development, specifically how you learn these skills.

When you cook, if you have eaten before, you base your cooking on your experience mixing up the ingredients and how they will taste once they are combined in the dish. Similarly, when you are coding you apply your experience creating structures and combining them together.

If you are new to software development this reaches a whole new level. You suddenly are cooking, but you have never eaten before. You have to taste every ingredient and food you want to mix before you can even think about combining them together into a dish.

Guiding a group of six people that want to become software developers is a big challenge. As the master chef I have to give them little taste of ingredients and letting them savour them, play with them. Slowly, while getting used to the structures (Strings, Numbers, Hashes, Arrays, etc) they will see how they can combine them into a cohesive self.

Even if you are an experienced developer, it helps a lot if you spend some time now and then playing with your ingredients (the data structures of your language). This way you will find new ways you can incorporate them into your applications.

> …you should refactor your code once you feel it’s time for it…

I recently read those words in a TDD mailing list.

What’s wrong with it?

First of all the TDD cycle includes a refactoring step (no matter if you are doing test first or test last). If you are not refactoring as you go, you are not doing anything other than writing a bunch of tested code.

So you are testing it, that’s good already, but are you actually caring about the work you are producing?

If you write code and don’t refactor as you go, with each passing tests, you are heading towards your own demise. Your code will grow and will become hard to change.

Some teams, that don’t refactor their code as part of their TDD cycle end up having to spend time refactoring as an task on their project.

It’s a hard proposition to sell to a customer; seldom you will find people that want to pay for the mess you have created all by yourself…

Yesterday I was having dinner with Matt and we had some really interesting conversations.

One of them made me think quite a bit about the different styles of coding and the underlying forces that are a possible cause to them. We were talking about declarative vs. imperative styling codes and the possible causes of them.

The obvious thing would be to say that some developers are just unfamiliar with the declarative style and therefore simply lack experience in this way of coding.

The more interesting possible cause though is trust, or how the company is structured.

I tend to use an imperative coding style when I am unsure about a 3rd party library or service I have to integrate with. When this happens I just stop and write a learning test. In this tests I try to understand what that library or service is doing, how it’s implementation works and what I can expect from it once I integrate it in my projects code base. I do this because I don’t trust the library/service or my ability to grasp how it works. Due to this lack of trust in either the libraries or my own capabilities I write imperative testing code.

When I am writing application code (and tests) I do the opposite. I write my code and my tests using a declarative approach to coding. I want my code and the testing code to read as a book. I want to tell a story; most of all though I want to express in my code what I am trying to do and not how I am trying to do it.

Back to the trust issues though. Some people work in companies where there is an inherit lack of trust. The managers don’t see the development team as seasoned professionals, the developers hold grudges against the testing team, etc.

Writing a story; concentrating on the readability of your code and how to express yourself better in this environment is a really hard task to do. Developers end up writing code the same way as they feel; defensively. In the battle for gaining control they end up doing what the management team does to them command the code to do their bidding.

There is much more to this and more that can be extrapolated from it. I think it’s a very interesting aspect of the group dynamics within a software development organisation and I think there is much more to explore in this area. For the moment I will leave this as such in hopes that we will learn more about it and be able to help those teams in need.

I have been using Things for mac for ages now. It’s a great tool to get yourself organised and plan your work (I will write something about my GTD method soon).

For some time now, since summer 2011, I have been moving all my content into the cloud so that I can keep my mac slim (at least from the point of view of data).

A friend of mine, Chad, moved to Berlin and started working with this company that you might have heard, the wonderful six kids, or 6 Wunderkinder.

They have a really wonderful todo list application, Wunderlist, that I had looked into long ago, but not in anger (as they say). The other day I downloaded it again (possibly because Chad is there now), and today I have made the decision to switch full time.

Why you may ask?

The answer is simple, unlike Things, Wunderlist is not a boring todo list, it’s beautiful!

Okay, okay, it has some really nice functionality to it that Things actually doesn’t have ;)

Recently I changed to Ruby 2.0.0 in a project I am working on. I think I am going to share some things that I found specially attractive when I find them in a series of small posts (this might be the only one though)

In the few weeks I have been playing around with Ruby 2.0.0 I really have come to love named parameters. You know them already from other languages (in Smalltalk and Objective-C, for example, you find this type of function calls) and I always have loved them for the clarity in the language they give. It is much easier to compose a meaningful sentence and make the messages you send across much more explicit.

There is one thing about the Ruby’s implementation of the named parameters that I am really fond of though. Let me show you first how the method definition looks now:

What does all this mean in practical terms?

Imagine you have a Use Case you are working on, it shows a project for a user in a project management tool. This method could look like this:

As you can see we are looking up the user and the project by their names and then passing them to a presenter wich will render the project board; a simple task.

We can argue that the user and the project should not really be looked up in the method body (they are needed for the presenter to render the page, but are a possible violation of the Single Responsibility Principle, if we are being purists about it) as the method is only in charge of showing the project (as it’s name indicates).

The beauty comes from what we can do now with it due the new flexibility Ruby 2.0.0 gives us.

And suddenly our method follows the Single Responsibility Principle again!

Obviously all this can be overdone and I would recommend you to explore the possibilities before you start messing up your production codebase.

Remember it is all about making your code clearer and cleaner!

Update!

As Chad mentioned in the gist, something similar as I show above can be done in Ruby 1.8.x already. I was to eager to get the blogpost out and I forgot to add a little spice to the method so that it would become cleaner and more readable:

If you look at this now from the clients point of view it actually becomes a nifty method call:

Thank you for pointing it out Chad!

Humans love stories; in the past stories were used to transmit important cultural events from generation to generation, we read novels that transport us to a different reality, we watch movies… the list goes on and on.

As developers we deal with language every day; be it a programming language or the natural language we are speaking with our team.

Why does our code not tell a story?

It starts with the obvious; when you are working on an acceptance testing tool (like cucumber) you are afraid not to capture every nuance of the system; you end up writing imperative scenarios.

If I read a list of things your system can do, like the back of a productbox, I will get bored.

Boredom is a dangerous thing!

I will disengage from your description, not really care about the application you are describing; over time I will let it wither and die.

If on the other hand you tell me a story, I will devour it, you will make me dream, seeing the users interact with the system in my head imagining their faces and reactions; You will catch my attention!

Reading a compelling story is always beautiful and engaging, if you become part of the story magic will happen!

Next time you write acceptance tests, unit tests or code think about me, the reader, your fellow co-worker and make me want to be part of that story…

Last 4th of April I gave a talk on the Impersonator Pattern during the CukeUp! event at SkillsMatter.

Before my talk I was talking to Andrew who also presented during the conference and we had a nice idea about how to improve my impersonator pattern.

There was always one thing that was bugging me about passing the world into the impersonators; nothing wrong with actually passing it in, but more a case of what happens inside the impersonator when he interacts with the world itself.

Consider the current state (as I have implemented an impersonator up until now):

The code in here is not as dry as it could be and it has always bothered me to some extend.

Now, what about we did implement method_missing instead? This way we could delegate all the unknown calls to the world and DRY up our impersonator a little further:

In this tiny examples this little improvement might not seem like a big deal, but when the actions your impersonator is doing involve a lot of interaction with the world it can be a huge improvement reducing a lot of duplication in your code.