Nerd Dinner, Recap

I didn't quite know what to expect when I decided to go to my first Nerd Dinner last night. I was a little nervous, a little intimidated, and a lot worried that I would look like a complete idiot. I shouldn't have been nervous. I was more in awe of the opportunity than intimidated by the folks there. And I hope I wasn't a complete idiot.

I got to meet Scott Hanselman right off the bat (He sat down next to me). To my left, was one of the architects of VB.NET. I spent time talking with them about LINQ to SQL and my experience with the Entity Framework, and Scott encouraged me to blog about my experience working with both in the real world. I'll try to do that as soon as I can catch my breath and test out one more feature of EF.

We shuffled seats every 15 minutes or so, and I took the opportunity to get to meet a bunch of folks on the F#, C#, VB.NET teams, as well as the Silverlight Teams (working on the Line Of Business Toolkit, something I am really excited about), and the Powershell/WPF Team. Everyone was so friendly, and genuinely interested in hearing about my projects, and giving pointers on how to do things a little better and a little easier.

The last group I sat down with included Glenn Block, the Project Lead for the Managed Extensibility Framework. We got into a deep discussion of test driven development, something I am working on implement at my company. He brought in a crowd of people to contribute to the discussion and I learned a lot! I wish I had written down everyone's names to thank them later. Here are some of the points they made, paraphrased of course. My ehad was spinnign by this point in the evening.

They stressed a couple of fundamentals for how to do it (we all understood why TDD is important).

1. There are two types of unit tests: functional tests, and acceptance or validation tests
2. Functional tests should be written by the developer as they are writing the code to exercise the code they are writing. They should still write the test before the code, but the two are written at roughly the same time. Test what you are coding so you know why you are coding it.
3. Validation Tests can be written by the QA’s to test edge cases and to try things to make the dev cry, but have the benefit of being repeatable to save the QA time from needing to show the developer exactly what they did to break the code.

This is a little different from my original understanding of TDD and how I had envisioned we would implement it, but they were quite clear that we were headed for trouble if we tried to let the QA’s write all the cases. Not because the QA’s couldn’t do it, it was that the developers lost the advantages of writing their own tests to help them understand the requirements they were developing against. It helps to make the code clear and concise and to expose code ‘smell’ early on in the process.

The QA’s can still help to identify and clarify the requirements of each function, but it’s not until the developer believes they have met the functional requirements of the component that the validation tests should begin.
Anyway, I hope to go to many more of these dinners, and highly recommend it for anyone who wants the opporutnity to talk with, and listen to some of the really big thinkers in the development industry. My head was spinning the whole way home.