What a party it is! Even though the actual start is tomorrow and today was "just" workshops, I am already having a great time!

Todays highlight was definitely meeting Jim Coplien and listening to his provocative style as he recounted seven ways agile teams fail. It was all business, hard facts and no play (well, aside from the provocations and caricatures).

Tomorrow, I will be giving my talk on changing software with tests to back you up. It's kind of at odds with what Coplien talked about today, because I don't "care" much for the either the specification directed nor the fault directed aspects of using tests as a developer tool. I think the great benefit are the behavioral aspects. None the less, tomorrows talk will be pretty code-centric, not like my previous attempts - come check it out!

Speaking of the benefits of tests, we reflected on the Copliens talk on the way back in Niclas car, and missed the design and behavioral aspects: In saying that TDD is no better than code reviews (and other techniques)* I do believe that we are missing the point. It reminded me of Martin Rinard on failure oblivious computing: TDD adresses the fault-prone part of developers, I feel most older techniques lean back to the space of a more elitist view (uncompromising it seems to me). I find that it does not work, we need methods that help us with the human side of things. Most of the cases, none of the methods give us bug free software - and my take on TDD is that it neither finds faults nor guarantees behavior according to spec. It does, however, help us move forward when developing.

Am I too pessimistic?

On another note, namely speaking: I will be giving a workshop at the SPA 2007 conference in Cambridge in march, more on that later.

*I am being sloppy with the details here, it does not detract from my point, I think.

About a month ago, I started to explore some of the options available to us CLR coders if we want to use  BDD/specification style testing from a dynamic environment. Sadly, the executive summary is that currently, there aren't any working solutions available. Or - happily, I was thrilled to discover that there are many efforts underway that will provide us with such tools, and they will be complete pretty soon!

First off, I looked at the C# non dynamic BDD oriented tools: Nspecify and nspec. NSpecify is nice. I didn't like the external (extra compilation step) approach taken by nspec. Anyhow, what I really want is some dynamism!

So, then comes specter to the rescue. Specter is written in boo (a pythonesque like language) that offers many dynamic features beyond what C# 3.0 has (even some that ruby doesn't have, but then there are many that ruby has and boo has not), for example ducktyping. Specter is a specification style framework that lets you create NUnit test assemblies using a very concise and nice syntax. So, all was great until I hit some of the limitations: Boo does not support generics. So, I cannot test methods that return a generic list of something.

As soon as boo becomes ready for primetime, specter is the best choice I have seen so far because of it's nice environment where there is ample support (sharpdevelop 2 is really not bad).

Lastly, I thought - why not use rspec to test CLR code? I figured, I want to try that ruby CLR compiler they made in australia. Well, I downloaded it and took it for a spin, and checked the docs. It looks promising but it turns out that it does not create standard CLR assemblies yet, and it cannot access CLR assemblies: Whatever you create with the compiler lives it's own independent life.

Well, another thing that looks really promising, but alas, at this point in time there is no real solution. Boo is making progress on the generics side, and I assume that the garden point ruby compiler for the CLR will advance as well.

The future looks bright, we'll just have to calm down and relax a little longer.

The topic of the architect role in software development surfaced here at oopsla as well, during lunch. In common with many fuzzy concepts, there is an inconvenient confusion surrounding what an architect is, which overloads the term and makes it less useful. One issue we all agreed on was that it is bad for architects to stop writing code, architects that do not program any more get disconnected from the operative aspects of development. This phenomenon brings problems.

Without motivating that further, lets have a look around and see if we can't see a pattern in where we see that phenomena, or not: If this type of non-coding architect is  good, we should be able to find architects like that amongst the most productive, effective and best development teams. There should be people that we look up to in our field that are like this.

I don't think there are too many like that.

After lunch when we've talked about this, we listened to Joshua Bloch (from java fame, currently chief java tech architect at google) who said this at the beginning of his talk:

"If you code, which I assume that all of you here do..."

Immediately, I thought of the conversation we had during lunch. I do think that this is widely recognized as a problem in our field, and that it in turn is a symptom of a couple of problems, a major of which is the career path problem - where is an experienced developer to go? A company wants to keep the competence and knowledge that the individual has gained, yet he is not interested in becoming a "leader". One option is to give the developer a new title - "architect" - and then he can influence several teams. Up to this point, we are not actually doing so bad - this may all be fine.

But then something happens, at some point it becomes ok to stop coding, the motivation runs out, or the organization pushes so many papertasks on the person that he loses touch with how to program software.

We have to start thinking about issues like this, and more to the point start acting on those thoughts. We need competent architects (as well as tech leads and devs) to succeed! Just as we push and put high requirements on ourselves (I am speaking as a programmer), we must do the same for other roles working on or with the team. Remember, you have to start change wherever you are, talk about the problems in a constructive way - what do we loose when people who cant remember how to create software actually dictates the design and creation of it?

Once you are or have a great architect on your team, be happy for they are fairly uncommon.

I was just informed that Bertrand Meyer is also coming to Öredev 2006! This is great news, I have never heard him speak - another good reason to come to Øredev in November. Martin Fowler, Jim Coplien, and just a host of other great people are coming. Speaker overview.

TDD offers benefits in terms of both project/work dynamics and software quality. Some benefits are obvious (feedback from tests) but most are not (small steps lead to a higher frequency feedback loop and more control). One view of this is that some benefits come as a by-product.

TDD / BDD (I'm going to use BDD from now on, substitute as you see fit) gives testability as by-product. This is basically the view expressed by Jungmayr.

The simplicity of the BDD method makes it general, flexible and adaptive. The flipside to that flexibility is that there is ample room for misunderstanding.

Does BDD prescribe testability? No. Indirectly, your designs *should* become testable if developed using BDD. However, there is no "step four" (after RGR) that says "review code for testability or maintenance issues and fix them". It is often not part of refactoring since testability affects design and "unit" (usually class, YMMV) functionality may indeed be altered.

Instead, BDD infuses many testability, maintainability and other factors of high quality software, through its focus on testing one small thing at a time, "small-scale tests", and eliminating duplication. In order to test just that one thing you must figure out a way to replace what it interacts with. You must be able to manipulate the link between them; you must make the dependency "loose". The consequence of this is that all classes will depend on each other loosely. They will not have hardwired dependencies.

Hardwired dependencies are when class A is coded to always use class B. This may be since it A itself creates B or uses static methods of B.

This makes the code less testable since there is no direct way to test a part of the system, by manipulating the dependencies. We have to use other means, via a more complex test harness, and/or tools.

So testability comes as an indirect result. But can we say it is a byproduct? Is it true that this is not a systematic way to get testability in our code?

Even though most misunderstanding is a product of ignorance, would there be a way to make TDD more explicit (in how benefits are addressed) by design? I am unsure, I agree with the idea that understanding in the form of realization is often impossible to transfer. It has to be experienced to materialise. Often, the best that can be done is offer guidance and direction, a map to where the realization of knowledge lies. The question then becomes if the benefits require such realization or can be reduced to following a systematic approach.