Last week's Test Driven Development workshop was just lovely. Although it was "intimate" - only 4 people actually showed up, it allowed for a more face-to-face conversation and attention. The whole idea behind this workshop is to let people experience TDD with an instructor - someone who points out the pitfalls and common misconceptions, someone who is there to say "No, you don't have a failing test yet". That was one of the things I wished I had when just learning this stuff out.
In the pictures you can see the folks are actually doing the unit tests, and are experiencing pair programming as well. Lots of smiling and joking was going on - part of what happens when you work with people who really want to learn.
In the pictures you can see Memi Lavi, Udi Dahan, Omer Van Kloeten (in uniform) and Or Meirov(no blog... yet!) - a "new" dude who happened to read my blog one day and decided he wanted to come over. I urge you all to do exactly the same.
After the workshop ended we had some great discussion about how does TDD and XP in general fit into service-oriented companies (fixed price projects) and what steps would be needed in order to make the development more open to this kind of change. Some stuff was brought up that I didn't even consider, especially by Memi, and for that I'm thankful. One of the coolest things about these workshops is that you learn just as much as you teach. I learned a lot about how people approach TDD and development, when Pair programming may *not* work and the role of the business side of things in introducing XP to the company. But I still feel like we're just at the beginning of discovering this methodologies and all its uses.
I didn't start out learning TDD. when I was a VB programmer (always will be, semper-phi!) I discovered this little thing called the VBUnit framework. It's the VB6 equivalent of NUnit, only because VB6 does not support inheritance or attributes you are left to use Interfaces to implement your tests and test suites.
I have to admit it took me a while to "get it". And when I did implement unit tests in my VB6 code - I did it all wrong. I did it in the wrong project, I ran the tests using a custom made executable because I didn't realize there was a test runner you could use. Lots of stuff. But Only later, when I read more about NUnit I realized how far away from the "vision" of unit testing I was. Why? There was no guidance.
With NUnit - people need this guidance just as much. It's fun to be able to provide this and watching the looks on people's faces when they hit a breaking change for in the workshop - and suddenly the NUnit Progress bar turns red.
I'll be speaking this Monday at the .Net architects user group on the basic concepts behind XP and TDD. See you there.