TDD: Microsoft is close but no cylindrical smoking thing!

MSDN has a page entitled Guidelines for Test-Driven Development
It has steps for getting going with TDD that state:

1. Define the requirements of your application.
2. Familiarize yourself with the feature areas of your application, and decide on a single feature, or the requirements of a feature, to work on.
3. Make a list of tests that will verify the requirements. A complete list of tests for a particular feature area describes the requirements of that feature area unambiguously and completely.
4. File work items for feature requirements and for the tests that need to be written.
5. In Visual Studio, create a project of the type you want. Visual Studio supplies the initial production code in the form of files such as Class1.cs, Program.cs, and Form1.cs, depending on the project type.
6. Define the interfaces and classes for your feature or requirement. You can add a minimum of code, just enough to compile. Consider using the Class Designer to follow this step. For more information, see Designing Classes and Types.

Note
The traditional TDD process does not contain this step. Instead, it advises that you create tests first. This step is included here so that, while creating tests, you can take advantage of two features in Visual Studio 2005 Team System: the GUI design capabilities of the Class Designer, and the automatic test-generation capabilities of Team Edition for Testers.

7. Generate tests from your interfaces and classes. For more information, see How to: Generate a Unit Test.
8. Compare the tests that have been generated with the list of tests you prepared in step 3. Create any tests that are missing from the list you wrote in step 3. For more information, see How to: Author a Unit Test.
it goes on...

While they do bother to make the note about traditional TDD, they are missing out on several major benefits of TDD:
• TDD is design as you go.
• When you use TDD the interfaces and classes you create emerge as an outcome of writing the tests. This helps to keep the code as simple as possible.
• TDD is about writing one test at a time to DRIVE the DEVELOPMENT of the code. This way the developer does not attempt to predict how the code (interfaces+classes) will look when finished, rather code that passes the tests will be written and refactored as needed.

Dave Glover: How to Globalise/Internationalise Dates and Numbers using the Compact Framework

I was chatting to Dave Glover from the Australian Microsoft team on MSN IM last night. He built this cool conversion app for the Smartphone. Some of the people who were downloading it in France were having some issues. I thought the issue was a globalisation issue and Dave figured out the rest: How to Globalise/Internationalise Dates and Numbers using the Compact Framework

Becoming Agile: How TDD improves development speed and is very cost effective

A common misconception is that test driven development will take longer and cost more.
Dan has a go at answering this on his blog .
A good read.
Becoming Agile: How TDD improves development speed and is very cost effective

Windows SideShow

Windows SideShow is a new technology that will be shipping as part of Windows Vista. It enables hardware to support auxiliary displays whose contant can be defined in Windows Vista software.
SideShow is a project I helped out on by reviewing the APIs and building some sample code. Some of that sample code has been morphed into the examples that will ship with the Windows Vista Platform SDK.
I am looking forward to getting my first machine that supports SideShow.

New Forums section on ViaVirtualEarth

We have just launched a new section on the ViaVirtualEarth site to help developers communicate about building with VirtualEarth - check it out.