There's been some pushback recently, in the .NET blogging community, about Microsoft's habit of living in the future. For example:
It is abundantly frustrating to be keeping up with you guys right now. We out here in the real world do not use Longhorn, do not have access to Longhorn (not in a way we can trust for production), and we cannot even begin to test out these great new technologies until version 1.0 (or 2.0 for those that wish to stay sane). I know there's probably not a whole lot you can do, but this is a plea to you from someone "in the field". My job is to work on the architecture team as well as implement solutions for a large-scale commercial website using .NET. I use this stuff all day every day, but I use the 1.1 release bits.In the spirit of Michael's plea, I'm working on an upcoming article in which I'll compare what was promised for the .NET platform (er, framework), two and three years ago, with the current reality as it exists today. Examples of the kinds of issues I want to consider:
Here's my point, enough with the "this Whidbey, Longhorn, XAML is so cool you should stop whatever it is you are doing and use it". Small problem, we can't. Please help us by remembering that we're still using the release bits, not the latest technology. [Michael Earls]
Easier deployment. The "end of DLL hell" was one of the early .NET battle cries. CLR metadata, enabling side-by-side execution, was going to make that problem go away. Well, has it? I hear a lot about ClickOnce deployment in Longhorn, but does the existing stuff work as advertised?
Unified programming model. It was obvious that wrapping years of crufty Win32 and COM APIs into clean and shiny .NET Framework classes, and then transitioning app and services to that framework, wasn't going to happen overnight. But, how much progress has been made to date?
Programming language neutrality. Here's a statement, from an early Jeff Richter article about .NET, that provoked oohs and ahhs at the time: "It is possible to create a class in C++ that derives from a class implemented in Visual Basic." Well, does anybody do this now? Is it useful? Meanwhile, the dynamic language support we were going to get, for the likes of Perl and Python, hasn't arrived. Why not?
Security. As security bulletin MS02-06 ("Unchecked buffer in ASP.NET Worker Process") made clear, not everything labeled ".NET" is managed. Still, there is a lot of .NET-based server code running now. Can we articulate the real benefits of .NET's evidence-based approach to code access security? And what have been the tradeoffs? For example, I've noticed that while .NET's machine.config adds a new layer of complexity to an environment, nothing is subtracted. You've still got Active Directory issues, NTFS issues, IIS metabase issues. How do we consolidate and simplify all this stuff?
XML web services. I'd say many of the original goals were met here. Of course the goalposts moved too. .NET Web Services, circa 2000, looked more like CORBA-with-angle-brackets than like service oriented architecture. But while Longhorn's Indigo aims for the latter target, it's worth considering how well the deployed bits are succeeding on their original terms.
XML universal canvas. I hoped the XML features of Office 2003 were going to deliver on this promise. But here, the jury's still out.
WebForms/WinForms. This is a tricky one. The original .NET roadmap charted two parallel courses for client-side developers, one for the rich client and one for the thin client. Or as we say lately: "rich versus reach." There wasn't a write-once strategy for combining the two -- and indeed, in Longhorn, there still isn't -- but it's probably useful to consider how the side-by-side strategy has played out.
Software as a service. Not much progress there, as Bill Gates acknowledged in a July 2002 speech in which he also lamented the failure of "building block services" -- what was envisoned as Hailstorm -- to emerge. What are the roadblocks here? Plenty of business and technical issues to consider.
Device neutrality. The Tablet PC has turned out to be a good platform for .NET apps. Phones and PDAs, less so, for reasons that will be interesting to explore.
User interface / personal information management. A bunch of important themes were sounded in the 2000 .NET rollout speech. Pub/sub notification. Attention management. Smart tags. Today, I'd argue, I'm getting a lot of these effects from blog culture and RSS. Going forward, Longhorn is the focus of the UI/PIM vision articulated for .NET. But living here in the present, as we do, it's worth considering which aspects of current .NET technology are making a difference on this front.
Over the next week or so, I'd like to have conversations with people on all sides of these (and perhaps other, related) issues. I'll be speaking with various folks privately, but here's a comment link (rss) for those who want to register opinions and/or provide feedback.
Former URL: http://weblog.infoworld.com/udell/2004/01/27.html#a900