Waiting to Inhale The recent Professional Developer Conference (PDC) fostered great excitement about the power of the .NET Framework v2.0. Unfortunately, it is going to be well into next year before most developers even get a whiff of all things Whidbey; and that's only in beta form. Some important .NET language and framework enhancements are in a big holding pattern, though, and I don't think that's right. Any Microsoft-sponsored conference, whether it be Tech Ed or the PDC, ends up being a double-edged sword. You find out about all sorts of great tools and technologies that Microsoft is cooking up for your development pleasure. Then, the other shoe drops, and you find out that you have to wait for months (sometimes years) before you will be able to actually use them. The technology tease du jour at this year's PDC was the .NET Framework v2.0, most notably known through its more visible counterpart, Visual Studio .NET Whidbey. I wasn't able to attend PDC this year, but I have been using Whidbey for a few months now as a member of the Whidbey alpha program. While there are some features of the Whidbey IDE that I would absolutely love to have today (such as more complete IntelliSense and the MasterPages page template designer), the new .NET Framework itself is what I'm really after. Many new features have been added to the C# language since the v1.1 timeframe (most of which will make it into VB .NET as well). Aside from any necessary bug cleanup, these features appear ready for prime-time, yet they won't see the bright lights (or monitors, as it were) of software development nirvana until well into next year. Similarly, there are hundreds (actually thousands) of new .NET Framework classes that I am just dying to put into production use that aren't available right now, but will soon join C# in a big holding pattern, waiting for Whidbey to be stabilized, polished, and prepared to ship. I'll be the first one to step forward and say that I am glad that Microsoft is taking the requisite time and precautions to ensure that the next version of the .NET universe is even more robust, secure, and powerful than the sterling product that they have already turned out. I don't agree with their idea of a coordinated ?ber-launch of the whole kit and caboodle, though. By their very nature, software development architectures have to be developed in stages. Language enhancements are followed by framework enhancements, which are then followed by tool enhancements. Tools are the last link in the chain, so they are obviously going to be the last ones finished, but that shouldn't stop Microsoft from releasing the .NET Framework v2.0 itself. Imagine if Microsoft decided to hold off on shipping Longhorn until the first round of third-party applications for it were finished. We'd have to wait another two presidential terms to get our hands on it. When the OS is done, let us have it. Likewise, when the .NET Framework is done, let us have that, too. Technologically speaking, the end result would be the same, but it would allow developers who weren't solely dependant on wizards and fancy developer tools to get a jump on using the new functionality that Microsoft is going to spend the next year or so hyping. The launch of the new .NET Framework without the Whidbey IDE won't be as sexy or glamorous (did I just associate those words with software development?), but I can guarantee that the decision would be embraced wholeheartedly by developers who aren't afraid of putting in a little extra effort to tap into a powerful new resource. Hell, I built angryCoder.com using Notepad during the beta days of version 1.0 of the .NET universe, so I am familiar with both the challenges and the rewards with such an endeavor. The productivity gains that I could get from partial classes and generics alone are enough to make it all worthwhile for me. Of course, Microsoft undoubtedly has ulterior motives that prevent them from exercising their option to release the .NET Framework before Visual Studio .NET Whidbey. With a coordinated launch of an entire .NET universe, Microsoft ensures itself of first-mover-advantage in the developer tools space. A .NET Framework-only launch would open the door for another vendor to release a competing developer IDE before Whidbey was ready. Developers might jump ship to the competing IDE as an alternative to more rudimentary text editors, even though Whidbey will undoubtedly be the best .NET IDE for version 2.0 (the cynic in me hates to concede this fact so early, but history speaks volumes). Some of you might argue that Microsoft already does what I want through the combination of their beta program and "go-live" license program. Unfortunately, many companies have strict policies against putting beta software into production (regardless of developer assurances of stability). So Microsoft, consider this an open request for you to give us the goods as they become available, instead of making us wait and then inundating us with new technology. You've got us hooked, now reel us in. | & | | 
By: Jonathan D Goodyear
jon@aspsoft.com |