Don't chain yourself to your install base.

When I worked at The Very Bad Place, we had an MFC application with an install base of several thousand users spread all over the U.S. It talked DCOM to our corporate servers to get its data. DCOM wasn't a completely insane decision at the time it was chosen -- there were far fewer remoting choices for Windows back then.

What was insane, however, was the admins not knowing enough about DCOM and TCP ports so that the company had to leave the DCOM servers sitting outside the firewalls.

I arrived at that scene back when SOAP was the new Golden Hammer. We probably could have handled most of their security issues with the SOAP-tunneled DCOM that COM+ offered, but that involved some strange inter-departmental politics, so the idea never took flight. They also had the IT departments from a lot of their customers planting the word SOAP in upper management's ears. Thus is the nature of Golden Hammers. So they hired me to put SOAP shims on the client and server so that most of the rest of the system still thought it was talking DCOM. It was all about Microsoft's SOAP toolkit back then.

The basics of tiered design had been abandoned for so long, that not only was the client sending raw SQL straight up to the server, it was even providing the name of the server and the database instance that the SQL should be thrown at.

So, basically, a horror show. But I get my SOAP shims implemented, we release a new version, thousands of clients install it, there was much rejoicing. Even a small performance boost because of a horrid on-server temp-file hack I was able to get rid of.

So all better, yah? No. Because roughly 80% of the install base upgraded. Leaving 20% of the install base still talking DCOM. Meaning that DCOM servers still had to sit with their arses in the wind asking to be hacked at.

And those SQL queries going across the line? It means we can't change our tables until every last client is gone. But we really need to change our tables because they're basically a mirror of a COBOL database, most some 50 columns wide, and it takes 6 hours for the nightly population script to run.

So these are the reasons most shops are so keen to go with web-based applications, and it certainly sounds like I just made a fine argument in favor of them. But we've been lost in this knee-jerk web-enablement world for so long, that I think most have forgotten how much easier it is to develop a thick client app. Besides the fact that they are a lot nicer. It's not the memory consumption anymore. Right now the two biggest memory consumers on my box are Firefox at 48MB, and IE at 40MB. (Sorry, Firefox, Task Manager doesn't lie, maybe it's all those silly plugins I installed.) Microsoft had to stop calling them thin clients. Right now Visual Studio is only taking up 36MB.

But AOL figured out another solution a long time ago, and Microsoft a little (okay, a lot) later. Automatic Updates. And that whole concept is built right into .Net smart clients. Security sandboxes, code verification and signing -- everything you'd want out of a web app without sucking. Gmail is really impressive, but I'll take Outlook, thankyouverymuch. Or Thunderbird.

If you're trying to reach a huge audience of previously anonymous customers, then a web app is obviously the right way to go. Amazon has to be a web app (and an impressive one it is at that, but if they wrote a thick client, I'd sure as hell give it a spin. You hear me, Amazon?). But what if you're just going to have a few thousand users? A few hundred? And they already have to register with you and write you a check? Do you think they enjoy waiting for the page to refresh?

Obviously, there would be a tremendous increase in time spent testing installers, and the upgrade process, and OS version compatibility, and yadda yadda yadda. But development time would go down by just as much, I would think. And developers cost more than testers and admins.

And .Net has done a lot for getting rid of the compatibility and library version issues that an MFC or VB app used to have.

Of course, my Linux brethren are hissing at me right now. And I say -- Mono!