Recently I've been actively involved in many discussions on the internet about Microsoft's release of .NET 2.0 and the impact both the upgrade as well as the original transition to .NET has had on development...
It's interesting to note that even the big boys have difficulty assessing the impact of their own changes on their clients. In the case of Microsoft's .NET technology, their clients are developing solutions of their own and they must assess how changes will affect their client's solutions, ultimately affecting the end-user. So, how does Microsoft perform compatibility testing? Let's take a peek...
Here are a couple of interesting articles on Microsoft's investment of .NET within their OS:
» How One Person Believes Microsoft Abandoned Its Developers
» Documenting .NET in Microsoft Operating Systems
The seemingly extreme moves by Microsoft in the .NET world have been disappointing at times and down-right ugly as well. I could have puked when I saw all of the new things to learn in the .NET 2.0 release after working so hard to learn 1.0 and after investing so much development time in things that would now likely be thrown away for new features in 2.0.
*At times, I worry about what I might have to do in order to handle the next big transition from MS. I think my employer is also pondering what life would be like using open-source technologies. But, as always, an investment has already been made and the decision to change would require an up-front investment that might not be available.
My take-a-way:*Now, if they try to throw XAML at me any time soon, you can bet that I'll be highlighting my PHP/MySQL skills on the resume and studying JSP and Ruby on the side.
The following is a reply from Tim Heuer, a Microsoft employee, supporting my suggestions that Microsoft's .NET development is not focused on investments in their OS, but rather in extending their existing products.
"The views expressed below are Tim's and do not necessarily reflect the views of his employer. All postings are provided 'AS IS' with no warranties, and confer no rights."
Are we losing investment in .NET - no way. Some quick thoughts...
- Don't write an operating system in managed code - managed code is not right for every scenario and Microsoft has never claimed that it is. Use managed code where it makes sense. For Java, I think it's fair to point out that Sun's Solaris isn't written all in Java
- We're still a C++ company - We continue to make big investments in C++, especially with C++/CLI. Microsoft still fully supports C/C++ and we have a very large existing C/C++ code base internally and a large C++ customer constituency.
- There are plenty of profitable products from Microsoft that use managed code including Windows, Windows Server, Office, SQL Server, and all of our Web properties. In fact, our highest growth products are predominately in Server & Tools where we have the highest revenue growth rate.
- We have millions of lines of managed code
- Visual Studio 2005: 7.5 million lines
- SQL Server 2005: 3 million lines
- BizTalk Server: 2 million lines
- Visual Studio Team System: 1.7 million lines
- Windows Presentation Foundation: 900K lines
- Windows Sharepoint Services: 750K lines
- Expression Interactive Designer: 250K lines
- Sharepoint Portal Server: 200K lines
- Content Management Server: 100K lines
Tim - your bullets about managed code investments reinforce my take-a-ways.
My hope is that Tim and other Microsoft employees simply continue to recognize the development community's frustrations with an open mind and continue making great software. My personal opinion is that most MS employees I talk to are very quick on their feet to "react" by singing a song of unsung heroes, which is totally unnecessary, since most "due credit" tends to be unspoken and criticism is always knocking.
Okay... The learning curve was like this: If I were required to change from coding VB6/ASP to Java/JSP. And then Struts came out. (I'll note the obvious exception that VB.NET and ASP.NET have visual similarities, but they are truly that different.) Down the line I'm seeing completely unfamiliar (though exciting) technologies like WinFS, WinFX, and XAML coming at us like an unstoppable train. In the short term, I'm wondering if things like Office 2003 "InfoPath" are worth developing for, because 1) there is no backward compatibility and 2) Microsoft might decide to re-write it, coming up with something completely different like "2007 LiveStream" (made it up--use it if you like) with hardly any upgrade support for my InfoPath solutions.
Some of my frustration with .NET-related enhancements is attributed to my team's slow, slow (did I mention slow?) adoption of new technologies, but I think there are many teams out there just like us... We still have ASP applications that won't be rewritten for another few years. It's just not possible to make the investment... again. (devil's advocate) If we had made the investment in JSP, there would be hardly anything (possibly nothing) to upgrade. If we'd upgraded to PHP, the same is true (more about PHP later).
As Tim mentioned, there's no avoiding upgrades.
I had no trouble transitioning to .NET 2.0. But, there was a LOT of new "enhancement" stuff to learn (on top of SQL 2005). And, I DO have to re-write quite a few things in order to leverage new capabilities that didn't exist in 1.0, because I had already written my own implementation or purchased a 3rd party solution. Example: my hack of a solution to skinning now completely changes--I suppose a "thank you Microsoft" is in order. Old .NET code will mostly still work, but certain upgrades are required as a future enhancement-compatibility investment.
With the 2.0 upgrade (without a full run-down) I was referring specifically to the ASP.NET master pages, themes & skins, web parts, and built-in security and personalization engines as well as the expansive "out-of-the-box" controls and providers; many of which I feel like should have been at least partially included in 1.0. These are all EXTREMELY exciting enhancements that make my job easier... once I learn how to effectively use them. AND, once I re-factor or extend my programs to use them (in VB6 this wasn't a realistic option). I'm not one of those developers that grows stagnant once I land a good job and even I am having trouble keeping up. Other developers on my team are not so enthusiastic. By now, my boss (a developer wearing a manager hat) has learned more .NET than everyone but myself.
I can speak for my team when I say that we're just disappointed in the sheer distance Microsoft jumped in both of the transition to .NET. I believe most people agree when I mention fading support for VB6. Personally I hated that language, but people made HUGE investments in it and, in my opinion, Microsoft left them for their trophy .NET wife.
My bullet-point arguments were mostly the "pros" to Microsoft's decisions (in my opinion). I'm all for enabling developers to make better solutions more efficiently with higher quality. But, business dictates backward-compatibility (speaking to all the VB6 KIA and MIA).
PHP: The most notable change from PHP4 to PHP5 was class-based. However, to upgrade, the changes are relatively minor. PHP makes absolutely certain that as many applications will continue to run without change as possible. .NET is doing the same. But, (again) VB6 to .NET? And, yet again, I know "why", but that doesn't stop me from being disappointed (mostly in the fact that VB6 ever existed ;)
Finally, the set of technologies that may come our way (XAML, WinFS, WinFX, Avalon, Indigo, you name it) are extensive and completely new. The scary thing about these new technologies is the same as with .NET: COMPLETELY new. Not an upgrade to some core that is always the same (with small exceptions).
When my spidy-sense is tingling and I know stuff is coming at me, I learn and adapt and you probably will to. But, there will be unfortunate casualties.