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 10: Future-proofing
It's the nightmare scenario that every IT planner dreads: You allow your installed base to fall behind the technology curve, only to find yourself unprepared when that next killer app appears over the horizon. However, in the case of Windows XP, you have the world's largest installed base on your side. Nobody in their right mind will try to force obsolescence on you anytime soon. Whether it's something simple, like an updated API, or more radical, like a complete paradigm shift, chances are good that the relevant components will be supported on Windows XP for many years to come.
With virtually the entire .Net 3.0 Framework supported on Windows XP, there are no significant advantages to running the latest Windows application model on Vista, outside of a few graphics acceleration functions (some window painting functions get a boost from the Desktop Window Manager). Even Microsoft isn't stupid enough to force the migration issue, especially after the very public backlash that has hobbled Vista adoption for over a year now.
But perhaps the biggest insurance policy for Windows XP loyalists, and the crippling knockout blow for Vista, is the impending arrival of Windows 7, due within the next 18 to 24 months. The idea that IT shops will encounter some kind of showstopper issue between now and late 2009 (the rumored target time frame for the Windows 7 release) has little credibility.
Decision: If ever there were an opportunity to skip a Windows upgrade cycle, the XP-to-Vista transition is it. XP may be showing its age, but its age is mainly skin deep: The new challenger is flashy, but also slower and heavier, and it lacks a killer combination of compelling features needed to unseat XP.
At the end of the decade, when Microsoft's executives look back at the debacle that was Windows Vista, they'll see that simply slapping a fresh coat of paint on an otherwise aging Windows architecture wasn't enough to fool anybody. Let's hope they also realize that, as with any major update, they needed to make their case to IT. Focusing on consumers while ignoring their enterprise customers, and assuming IT shops would simply fall in line, was no way to execute a platform migration.
Here's hoping that Microsoft indeed learned its lesson, and will engage us early and often when pitching the promise of Windows 7.