In this period I’m teaching Test Driven Development in various teams in which this practice is unknown. During the course I use some non-Microsoft tools (mbUnit, RinhoMock, TestDriven.NET, …) and I see that one of the big obstacle is the use of these tools.

I ask myself why and the answer could be double.

The first answer is that the programmers are lazy and they don’t want to learn the use of new tools that are not always so easy to install and learn.

The second answer is that a lot of tools are not well integrated in the IDE and take time to get confident with their usage.

I think that for a massive use of these practices (Test Driven Development, Continuous Integration, the use of a Source Control System) the various supplier of these tools must do a little step to that lazy developers to give them the needed integration that a Microsoft developer wants. One alternative solution is to wait that Microsoft release some tools that are usable for these practices (and not too expensive!) and for what I see Visual Studio 2010 is on the right way.

Last week I was at teched emea in Barcelona. This was the second time there and it was better than last year maybe because I followed more technical sessions.

Here are some reflections:

- WindowsForms is dead. There was 300 sessions at TechEd and only 1 was dedicated to WindowsForms and that session was canceled. So think about it if you are starting a new Windows Application: WPF rulez!

- Cloud Services. Announced at PDCsome weeks ago they are the big new for next years. Our application can be hosted online somewhere in the “clouds”. The big obstacle that I see is the Data. Here in Italy the customers are very jealous about their data and not everybody will agree in keep the data outside in the clouds.

- Parallel Programming. A lot of sessions on this theme. In near future we can’t develope application without think about it. The multi core processors are everywhere and our application must use all of theme with right balance of resources.

- The relation database is more hidden than ever. Pat Helland and David Chappelhad talk of destructured data and the Sql Data Servicesworks with gerarchic data. We can build our entities using properties that have a Name, a Type and a Value but the source are heterogeneous and we can’t guarantee that they are the only properties maybe there are others that we need to manage.

TDD is often considered a practice for writing test. It isn’t: TDD is a design practice.

Time ago, while developing an application, it happens that I need to write a resource schedule algorithm. I’m not an expert in schedule algorithms, I read some paper, I know that exists various methods more or less complicated, but the one that I need was quite simple and so I preferred to write it by myself using small steps and TDD that helps me a lot.

I collected the specification from customer, wrote some stories and ordered the stories by complexity, then I begin to write the first test.

The first test try to schedule a single resource always free on a unlimited and free time lap. When this was green I wrote another one with 2 resources, then 3, then N.
Then I wrote other tests that reduced the available time, others that introduce overlapping schedules, to arrive to a test that reproduce real world cases with N resources on N projects with small time available.

What I did is to add a little complexity on every new test and having all the previous green test help me to stay on track and to keep the algorithm right. On every green test I did some refactoring to keep the design clean.

After 2 dozens tests I had the full algorithm ready to use with a suite of test that proved it. I don’t know if this is the best algorithm, I know that it is not the fastest one but I know that it satisfy the customer requirements.

Naturally after the deployment the customer begin to use it and she asked for some modification. If in general this kind on modification on this complicated algorithm is very difficult and dangerous to implement, if you have a suite of test that in a bunch of seconds verify that everything is going right you can write the new requirements quite relaxed adding new tests.

Here the TDD has a double value: first it helped me to resolve a complex problem step-by-step keeping always under control the status of the project, second it helped the introduction of new requirements requested by the customers.