Can small businesses afford the .NET size?

This is a followup to my entry on May 06 about Managed code and C#. This may sound like I’ve bought into the Microsoft story; but its really based on my experience as an independent software developer. Decide for yourself though…

The question is – as a small business, can you afford the hit of .NET to develop your applications if some of your customers may not be able to install .NET? Will the 23MB download of .NET be so big that it limits your distribution and prevents your product from being a success?

The answer is pretty complicated. Is your target user a personal computer user? Or a corporate user? Do you expect the IT department to install the product or will the user install it directly? You should think about these options before you decide what to do. Unfortunately, as with many technologies, using .NET is almost an all-or-nothing choice.

As for me, I’m a wholehearted believer in C#/.NET at this point, and I think most companies should elect to use .NET, despite the download. Here is why.

First of all, .NET ubiquity is growing. Microsoft claims that they already have over 80million copies of the .NET framework installed. From the Lookout stats, its hard to tell what percentage of users already had .NET installed, but I think its about 35%. How many users didn’t install Lookout due to .NET is almost impossible to calculate. But I do know that by bundling .NET installation into your install (which Lookout optionally does for users that don’t already have it), a lot of users are able to install easily. These users are probably broadband users, however.

The good news is that the .NET framework is being bundled with many new Windows installations today. The availability of .NET is only going to increase.

Here are some reasons you should use .NET.

1. Most developers agree they are more productive in .NET.
Developing in C# last year was eye-opening to me. The fact that two guys could build something as complicated as Lookout in a short period of time is just amazing to me. We’re not geniuses, we’re certainly not rocket scientists, but we were able to do it. A lot of it is thanks to .NET. There is no way we could have built an equivalent set of features in C++ in a similar amount of time.

I do think that Java offers many of the same benefits as C# from a pure development perspective. But the Java Runtime is even less distributed than the .NET framework. So, if you are looking to build in a managed framework where you won’t have to bundle and distribute the 20MB framework, C# is a better bet. For server-side applications, you probably don’t care about the distribution of the framework.

2. .NET is more reliable.
In the case of Lookout, we were building an application that had to exist inside of Outlook. Outlook is known to be one of the more treacherous programming environments out there. MAPI in particular (ask your developer friends) is a bit obtuse, and easy to screw up. Managed code, however, runs within a protected boundary. Because its completely interpreted, the native->managed wrappers put a big blanket around the .NET code. If your .NET code crashes or goes awry, its very easy to catch that crash so that it doesn’t percolate into the Outlook application itself. Its difficult to accidentally corrupt the main application’s memory space. Lookout has received praise for its reliability (although it has its share of bugs too), and a big part of this, I believe, is the fact that as managed code, it can’t screw up its hosted application. Consider if it were C++, however. If you have one bad pointer bug, you’ll take down all of Outlook! Thats a huge liability, responsibility, and just downright scary.

3. .NET is more performant than C++ code.
This may sound most controversial to many people. However, I believe it to be true. As a managed language, you may think, “how can it possibly be faster?” Well, you are right at one level. If your application is just a number-crunching app that wants to drive the CPU as fast as it can, you can probably write a more optimal algorithm in C++. But how many apps have that property? I’d argue almost none- except for pure research or scientific applications.

The performance of most real-world applications these days hinge on a combination of disk IO patterns, network IO patterns, and CPU patterns. This is a complex formula, and is generally difficult to optimize. Talk to any performance expert out there, and they’ll tell you that the way to optimize is to design your app, build it, and then profile, profile, and profile again. Use profiling to figure out where your hot-spots are, and then redesign those portions. This is where C# and .NET crush C++. The fact is that C++ is so complicated to maneuver in that refactoring based on profiling is a very difficult and time consuming process. Most companies simply cannot afford to spend much time here. Developers can discover the major bottlenecks, but except in extreme cases, they do not have the time or resources to redesign them. Instead, they will employ a set of “quick hacks” to work around the bottlenecks. These quick hacks become legacy problems for the codebase, and don’t fix the underlying problem. Over the course of a year, after a few patch releases, the C++ code remains largely stagnant due to cost considerations.

C#, however, can be refactored with much more ease. As problems arise, developers can much more easily rearchitect around performance bottlenecks. That profiling data does not go wasted – there is actually time to redesign large portions of the application without destabilizing the whole thing. Because of this, the 2nd and 3rd generations of a C# project will significantly outperform their C++ counterparts, and also be higher quality.

Case in point (and I am certainly biased here) is the Lookout MAPI indexer. I have tried a lot of the competitors’ products, and I believe the Lookout MAPI indexer is 2-5 times faster than any of the competitor’s indexers. The competition is written in C++. How is this so? We redesigned the indexing algorithm about 3 times based on experience and profiling. The C++ guys can’t keep up.

Conclusion:
Well, if its really faster, has fewer bugs, and takes fewer resources to build, you know my conclusion. Some folks may still want to have their applications target some of the old legacy machines out there (windows 98, etc), and if you really need that, C++ may be for you (although .NET does allegedly run on Win98 too). And, you can’t ignore that .NET does require more RAM; so it may not run as well on the older machines. Anyway, I just hope that Microsoft bundles .NET into a service pack sometime soon so that this whole distribution question can start to go away.