December Friday 16th we have had our second Italian Agile Day. It was a tough day for me, I had some flu and bad temperature the 2 days before. Luckily, some paracetamol and antibiotics helped me carry on until the end of the day.
I'm really satisfied by this year's edition. Compared to 1 year ago, this year we have had less presentations, no parallel sessions, but more insight and more depth IMHO. I was particularly impressed by Ferrari Racing Development Team and Francesco Cirillo.

Jim Freeze has an interesting post about writing DSLs in ruby. Check What is a DSL? - O'Reilly Ruby:

The third time around, after the Ruby DSL hype had been going around for a while, I decided to use Ruby. This time, I was able to create the DSL in about five minutes. It was readable, and I was able to focus on the end users frame of reference.

The moral of this story is, don't write a mini language if you don't have too. And, don't settle for a simple DSL when a full featured one is needed. Consider extending a GPL into a DSL. Particularly an expressive language that is good at creating a readable DSL -- like Ruby.

On the Italian Extreme Programming mailing list there was a discussion originated from my TDD live demo held on the Second Italian Agile Day (more on this in a later post). At a certain point of the discussion it came up the idea that TDD and OO design are not necessarily tightly connected. Well, I disagree and here's my take on that.

Let's put it simple: there is no TDD without refactoring, that is refactoring is a constituent part of TDD, not something beyond TDD that I can consider as an option. TDD micro-cycle is: test => red bar => code => green bar => refactor => green bar. If you don't refactor you are not following TDD.

Period.

Let's consider now that refactoring is OO. There is no refactoring without OO. The smells that you recognize into code are another symptoms for rigidity, fragility, immobility. Every refactoring move is justified by 3 criterias:

• enhance code readability
  
• reduce coupling between classes/modules
  
• enhance cohesion of classes/modules
  

Apart from readability, every refactoring move if correctly applied brings to OO design. What means correctly applied? It means if applying that move is appropriate, that is if it doesn't increase rigidity, fragility or immobility, that is if it doesn't introduce new smells. Refactoring means applying ex-post OO design principles.

Because of these reasons design is typically decomposed in several classes and responsibilities are fine-graned assigned.

Another period.

Is it possible to apply TDD following the functional paradigm? I don't know, my lisp reminiscences are too old. Today I would tend to write OO lisp code, merging together the good of both functional and OO paradigm. I'm quite sure that I would end doing something that is not TDD, probably closely related to, but not exactly TDD for what is commonly meant.

Naresh Jain's Weblog : Running Fitnesse inside the container

Simple and easy to follow steps to run Fitnesse inside the container:

We want the FitServer class to be invoked inside the web container. Then we can setup remote debugging on the web container and easily debug the fixture, business delegate and actual EJB code. This also helps us to avail all the EJB ref look ups and other container provided services.

A few days ago I found myself implementing fixtures where some fields where date-liked typed. To be precise, the customer was specifying dates in Italian format (ie: DD/MM/YYYY, like 24/11/2005), and corresponding fields in domain objects were typed with custom-type dates, incapsulating java.util.Calendar (to be honest, java.util.Calendar defines one of the worst hierarchies in whole jdk libraries; I still wonder what was drinking or smoking the designer of that hierarchy - but that's another story).

Fit has parsing facilities built-in for java scalar types and a few others (ie: java.util.Date). Therefore when you specify values of custom types you have a few alternatives:

• don't use custom types in fixtures, but rely on some other standard representation (ie: a date may be decomposed in 3 integer fields) ==> this seem somehow unnatural and cunning
  
• the fixture can override method public Object parse(String s, Class type) , which will be called polymorphically by TypeAdapter while parsing table contents ==> this is very good when you want to confine parsing facilities in fixtures only, but has the drawback of being limited to one hierarchy line only (unless duplicated in many fixtures, of course)
  
• the custom object T may define a static method like public static T parse(String s) , which will be called via reflection by TypeAdapter ==> this is best choice when you want to reuse the parsing facilities among different fixtures, but has the drawback of pollute application code with parsing services just for testing purposes
  

Third option was perfectly suited for the situation I was facing. As a side-effect I have redefined toString method such that for every T t instance t.equals(T.parse(t.toString())) .

Some months ago there was a discussion on the Fitnesse group concerning the possibility of having pluggable custom TypeAdapter classes, so that every fitnesse project can define its own parsing rules, common for all the fixtures, without polluting domain objects: I think it would be the best possible option, but we have to wait until a plug-in architecture will be defined in Fit for that.

In the end the message is: you can put a lot of extension points (or flexus points) in your design, especially if you are developing a framework. Nevertheless there will always be situations that your design is not able to tackle out of the box. That is to say, your design cannot be closed (in OCP sense) against any changes no matter what. This is true whether you are developing in a traditional, prescriptive manner or if you are an agile, evolutive follower.

Why Ruby is an acceptable LISP, by Eric Kidd

Eric Kidd makes a few fair and thoughtful points about ruby and lisp.

1. LISP is a dense functional language.
2. LISP has programmatic macros.

This post has been recognized as well in one of the most important blog of the lisp community. Very good news for ruby diffusion!

Credits to cas for mentioning it.

A few days ago I have spoken with the Industrial Director of an important manufacturing multinational company based in Italy. To give you an idea, they have several factories in Italy and a few in other countries, typically in the developing world. They are clearly a worldwide leader in their business.

He's a friend of mine, so the conversation was without any limitation and absolutely confidential. Of course, I cannot disclouse his name, nor company's one.

He is responsible for all factories production. He was helding a similar position at a local level in a much bigger US multinational company, a very very well known one, where he had the opportunity to see lean manufacturing in practice. Before that, he had just studied about lean, but nothing beyond that.

I was asking him: "How much is lean adopted in Italy?"
"Not that much", he said. "There are managers that don't know about it, even if the majority probably knows it. But the problem is that in reality it is not put in practice. There are companies that talk about lean concepts, but they are keeping it only at the surface."
Me: "Does it mean that almost all manufacturing companies are still sticking to Fordism and Taylorism? Or better, are they imitating Taylorism?"
Him: "Yes, sort of. If you are lucky you find somebody who has read something about lean, but not more. To give you an example, I'm looking for 2 Quality Managers for 2 factories, one here in Italy and the other one in [CLASSIFIED]: I'm not able to find anybody with practical experience in lean manufacturing. Only talking about it, trying to picture themselves in good shapes because they have read a couple of books. By the way the position is lucrative, the role is ambitous, but that doesn't help either!"

This situation is pretty common in Italy. There are many sectors where we are simply following many steps back behind other leading nations. This is sad, because there are capable people, willing to try new things, but not enough entrepreneurs or venture capitalists willing to take some risks. In theory we are prepared. In practice we are sleeping. We don't risk that much, but we are constantly declining away. There's an atmosphere that reminds me the fall of an empire, but without any imperial heritage. Well, not recent anyway.