I was even more eager to attend this one than the previous last session. And to be perfectly honest with you, I got the same results, disappointment in the first degree.

How can you get disappointment out of a TDD session with Jean Paul Boodhoo and Scott Belware? I ask myself the same same question and I am starting to get it just now. I'll try to clarify myself.

They are brilliant, passionate and communicative guys. Both has given a lot to the community. But both failed to deliver a satisfying session. But how? Not a single cause but several.

The Organization played their part in my not so enjoyable experience of the Post-Conference. From my point of view, it is unacceptable that in a coding-oriented session not every attendant was able to get a flat surface in which the laptop could be laid onto (and no, my lap is not flat enough, nor it's a comfortable and ergonomic posture). It may be OK during regular sessions but definitely it is not in an full-day coding session.

I mentioned in the pre-conference that net connectivity was not superb. They were more or less patched throughout the conference when there were various access points (APs) to choose from. But when the speakers require that all people in the room connect to the same AP to access their code repository, and the AP is configured to kick out people that outnumber the threshold configured it becomes a problem. Some guys (me included) had to copy the code from a pendrive. Organization? Speakers? Lack of communication between both? I will probably never know but it helped to damage the experience a little more.

The speakers changed the agenda one week before the session. That's a huge no-no. Neither me nor the rest of the audience was notified of the change of plans. From "Test Driven Development" (TDD) we went to "Behavior Driven Development" (BDD). Not a huge change, but still a noticeable change. Had I been notified I might had changed my mind and attended another session (not really, but that's not the point).

A nastier side-effect of the change of plans was that technical requirements to attend to the session changed as well. From Visual Studio 2005 we passed to Visual Studio 2008 (VS2008) with the alpha Resharper 4 as extension methods are the spice of the BDD toolset. And since we were not notified of the change of plans, many people did not have VS2008 installed and had to spent part of the session having it installed. Even if it was during the talkie part and JP kindly provided the software and helped with installation it is time they shouldn't have to spend installing anything in their laptops. It is more serious that it may sound as the speakers were running out of time and most of the interesting part of the exercise was rushed and/or non-existent.

The speakers did not do a good job either. If speakers ask for questions and topics to attendees in order to be addressed during the session they should make sure they get answered. Majority (vast majority) of questions that were asked by the attendance and written down in sticky cards on the wall were left unanswered. Some of the topics never were near hit. Too bad because they were interesting questions. Real-life issues with the techniques (and they were TDD questions, not BDD specific for the record)

Also, it's desirable that speakers stick to their plans. If they claim that the session is going to be interactive and highly focused in pair-programming where everyone is going to have the chance to implement one of the scenarios... stick to it. Maybe they did not have time because they screw up when changing the contents and requirements, but I still think that it could have improved the experience. No one paired. Sorry, that's not exactly correct. One of the attendees paired. Too bad that one of the multiples changes of implementations wiped out the existence of those precious lines of code of code. He almost cried when that evil Backspace key was hit. Me too. Such is my degree of empathy.

And the pairing point, introduces that last issue I experienced in the session. Multiple changes in the design lead us to no time to implement the interesting thing as most of the time was spent debating on how to implement the very same thing and changing it. I agree that there's no single correct way of doing things, there are as many as attendees were in the room. But do not let endless and fruitless (in my opinion) discussions exhaust the precious time people have to get the meat from the session. I really like the idea of code improvisation. But to a certain extent. You better have implemented the subject of your session before and at least have a clear target that must be hit, even when allowing the attendance some degree of interaction.

 

Way too long rant. It's not addressed to anyone ,but I felt I to lay out the causes that made my experience not as enjoyable as i would have been. If you look at the points in isolation, none of them is big enough (even though there are ones bigger than others) to spoil the a-priori wonderful experience. But if you add-them up, you get more or less my result.

Grumpy regards