Round 9: Developer tools support
As a commercial Windows software developer, I try to stay current on the product cycles for Microsoft's developer tools. Specifically, I like to keep a close eye on the evolution of Visual Studio. Visual Studio is my office for much of the workday, and I'm always looking for new and better ways to get things done faster and with less debugging.

Visual Studio 2005 was a great tool that suffered from nagging performance issues in the IDE and the general bugginess of the .Net Framework 2.0. Visual Studio 2008 addresses most of these shortcomings while also allowing me to target both Windows XP and Vista with new WPF applications. And like virtually all of Microsoft's developer software, it runs great on either OS. If anything, Visual Studio 2008 runs a bit faster on Windows XP, though Windows Server 2008 gives XP a run for its money in this regard.

Therein lay the rub: With no tangible advantage to running Visual Studio 2008 on Vista, and with some very tangible performance advantages to sticking with Windows XP as a desktop OS, it's no surprise that a lot of developers are still coding on the older platform. Functionally, you don't lose anything by writing code in Visual Studio 2008 – or any other commercial IDE – on Windows XP. And if and when you do need to test for Vista compatibility, you can choose from any number of free and commercial virtual machine managers to create the desired test conditions.

Decision: With most developers still targeting the Win32 API, and with virtually the entire .Net Framework 3.0 functionality back-ported to XP, there's simply no compelling reason to base your IDE on Windows Vista.

Round 1: Security
Round 2: Manageability
Round 3: Reliability
Round 4: Usability
Round 5: Performance
Round 6: Hardware compatibility
Round 7: Microsoft software compatibility
Round 8: Third-party software compatibility
Round 9: Developer tools support
Round 10: Future-proofing