Friday, September 02, 2005

Microsoft Doesn't use it, Why Should We?

As a Windows Forms developer, I do see my fair share of skepticism around the .Net technology. "Microsoft doesn't use it, why should we?" Well, I'll address the "Microsoft doesn't use it" part later but why should we? Because I've personally seen such an improvement in productivity that I really do think that moving forward into the future, its the right technology to use.

In fact, you can see the case study I did with Microsoft a few years back where I sold my soul to Microsoft. (check the video)

That isn't to say I've always thought that .Net was the right technology to use. About 4 years ago, I had a lot of concerns about using .Net Windows Forms for a very large Windows application suite. The decision was made to use .Net and I aligned around that plan however many of my concerns around size and performance ended up being problems.

What's changed since that point in time is that for many companies, supporting older OSs like Win 98, Me, and W2K are no longer a requirement. It isn't necessarily the OS versions that are the problem, its that older OS versions also imply slower hardware. Coupling faster hardware with the fact that Whidbey is a mature release of the .Net Framework that has made great strides in the area of performance, I reiterate that I believe that moving into the future .Net is the right technology for Windows applications.

That said, moving your Windows applications to .Net has its caveats and is not the right solution for all situations. It all depends on the requirements of the application being built.

The caveats are size, performance and the .Net Framework redistributable itself.

From what I've seen and understand, IL is actually smaller than assembly and that is one of the reasons in some conditions its possible that loading IL and jitting it can be faster than loading equivalent native code (say if you are really I/O bound). That said, assemblies comprise of metadata which I have found can significantly increase the size of an assembly and make them bigger than an unmanaged equivalent. In general though, for many reasons, it can be much easier to create a really small app in native, unmanaged code than using .Net.

I found that the overhead caused by having a managed environment has its effects on performance. In particular, cold startup perf can be an issue and in general, especially in Windows Forms applications, the application just does not respond as quickly as an unmanaged equivalent. That said, my experience has shown that the majority of the big issues can be worked around through an understanding of how the .Net Framework works and adjusting accordingly. Also, its important to note that Microsoft is making a lot of improvements in this area in Whidbey.

I've also seen .Net performance used as a scapegoat for the lack of commitment and investment in performance tuning. Don't get me wrong, there is a performance penalty, however, the majority of the serious performance problems I've seen on .Net applications have been algorithm related.

.Net requires re-learning how to make a performant application. For example, C# looks a lot like C++ but there are some fundamental paradigm shifts you need to make to become effective in using it. Here's an example on markda's blog.

.Net Framework Redistributable
The .Net Framework is around 20MB and on a decent machine takes about 4 minutes to install. That's a pretty big overhead for most desktop application deployments and it can be a killer for a web downloadable solution. There just isn't a good answer to this. If you developed with .Net 1.1, that framework is becoming more and more pervasive however we all want to use Whidbey :)

So there are some issues with moving to a .Net Framework based solution but every technology has its tradeoffs and many of the issues above will become less and less of an issue over time. You do have to balance what it is you are trying to accomplish and whether or not the issues with the .Net Framework are barriers to your success. If they are mere bumps in the road then I believe the long term answer is a .Net based solution.

Why do I think that? Mainly because of productivity. I feel that when you aren't fighting the technology, you can focus on the innovation. Much like creating great music requires removing the technical barriers of the instrument.

Additionally, great developers will be more productive and the not as great developers can be used in situations which, in the past, may have been reserved for the better, more experienced developers.

Which brings me back to the original question "Microsoft doesn't use it, why should we?". Dan Fernandez has a list of Microsoft applications that use .Net on his blog. They are moving to it and they are making a big bet by developing parts of Vista with it.

To be fair to Microsoft, many companies have large legacy code bases and even though they may be bought off that .Net is the right technology to move to in the future, they simply cannot do it for all of their products... right now. I believe it really is only a matter of time...


Post a Comment

<< Home