Dev Days 2006, Stockholm in December

Microsoft is arranging a asp.net focused event, Dev Days 2006,  in Stockholm december 5th. I have agreed to talk about databinding in ASP.NET 2.0. Tobias Fjälling will be talking about AJAX. There is little info on the site, and no abstracts, but Johan Lindfors has put up the info on his blog, here, among other posts. Note that neither me, nor Tobias are cornerstone employees - despite what Johans post may indicate.

If you're doing ASP.NET development, come check it out - it's an inexpensive event, and there will be lots to choose from.

SPA 2007, Cambridge in March

The 2007 edition of the Software Practice Advancement conference is held in Cambridge. I will be giving a session in the form of a short workshop exploring testability, encapsulation and how they relate to each other. The idea is that the topic will serve as the starting point for a short collaborative exploration of these concepts, and we will all leave with a clearer understanding of them.

Check out the awesome programme here, and details of my session here. The conference is actually very inexpensive, and whereever you are in Europe, catching a flight to the UK is dirt cheap nowadays - so give it some consideration. The lineup includes names like Dave Thomas (of pragmatic programmers fame), Michael Feathers, Tony Hoare, Brian Marick (brilliant test specialist, known to go out of his way to give non-planning swedes rides to airports), Kevlin Henney, and a host of others.

Øredev 2006 is over, and it was pretty great - despite several last minute  (quite literally last day) cancellations from some high profile speakers. I talked to alot of people and many agree with me that the social atmosphere was very good. The panel on the last day rounded off the whole event nicely. In the picture you see Martin Fowler, Erik Doernenburg and James Coplien.

My presentation went pretty well, it seems alot of people enjoyed it. Here is the slidedeck for it.

I forgot a couple of things: First, I forgot to announce the next SNUG meeting, which is December 6th in Malmö - sorry chris. I also forgot to underline the steps after vou've got the code you're interested in under test. I managed to cover alot, but there are so many important ideas that I did not have time to cover.

The last thing I missed was the resources slide, you will find it in the download. I have also put out an older version of this talk in an older blog entry, look for it. As you probably noticed, the sessions where recorded, and I hear that there are plans to make them available to all attendees. Time will tell.

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.