Here are my current thoughts on the gradual migration to .NET development tools at Fog Creek.
The status quo: Most of CityDesk is written in Visual Basic 6.0, with parts written in Visual C++ 6.0. Most of FogBUGZ is written in VBScript for ASP, with parts written in C++. Almost all of our internal tools and our web presense (Fog Shop, Discussions, etc) are written in VBScript for ASP.
Why bother moving to .NET at all? Simply put, it’s because .NET appears so far to be one of the most brilliant and productive development environments ever created. ASP.NET really makes it incredibly easy to create useful web applications; over the last couple of days I’ve been creating some applications we use internally at incredible speed. All the grungy stuff that takes 75% of the time creating web applications with ASP (such as form validation and error reporting) becomes trivial. ASP.NET is as big a jump in productivity over ASP as Java is to C. Wow.
C# has most of the good stuff from Java, with a few small improvements like automatic boxing. Although we have always done what we can to create reasonably object oriented code in ASP and VB6 in the past, switching to C# will be nice.
Finally, the class libraries that ship with .NET are great. The fact that everything, from data access to web development to GUI development, was redesigned means that there is incredible consistency from top to bottom. When you look at the old Win32 API’s, it is simply amazing how many different ways there are to get a string back from a function call, for example. Every two years they changed their mind about what a good way is to do this. .NET has cleaned that all up. I love the fact that you can use an ASP.NET calendar widget, which generates HTML that selects a date on a monthly calendar, and be confident that the “date” class you get back from that thing (System.DateTime, I believe) will be the exact same date class that the SQL Server classes expect. In the past you would not believe how much time we wasted doing things like reformatting dates for SQL statements, or converting COleDateTimes to someOtherKindOfDateTime. And finally — a string data type that works everywhere! Just last week I was writing ATL code and messing around with BSTRs and OLECHARs and char*s and LPSTRs and what a mess that was. Good riddance.
OK, I admit it — .NET violated the Never Rewrite From Scratch rule. Microsoft got away with it because they had two things. First, they had the world’s best language designer, the man who was responsible for 90% of the productivity gains in software development in the last 20 years: Anders Hejlsberg, who gave us Turbo Pascal (thank you!), Delphi (thank you!), WFC (nice try!) and now .NET (smacked the ball outta the park). Second, they put about a zillion engineers on it for about three years, during a period where much of their competition was more-or-less stalled. Remember, just because Microsoft can do something, doesn’t mean you can. Microsoft makes their own gravity. Normal rules don’t apply to them.
A few dozen people will now proceed to compose angry emails praising some other development environment, or asking why we don’t just use Java and get Write Once Run Anywhere (giggle), or Delphi (the talent has left the building. .NET is Delphi 7.0, and 8.0, and 9.0), or Lisp, or whatever. I am getting locked in the Microsoft Trunk! they will say. Regrettably, I don’t have time to get into religious discussions right now and I usually find them quite boring. I don’t care if Japanese is a better language than English. It just doesn’t matter. Let me finish describing our strategy.
First problem: we don’t know enough about .NET to write good code. As usual in any development environment there are many ways to do any given thing, and we haven’t quite learned the first way, let alone the second way. So the quality of .NET code that we can write is not good enough to ship. Until Bill Vaughn’s first ADO book came out, we didn’t even know the optimal ways to do basic SQL queries. So our first priority is education, which we will accomplish by doing all future in-house and web-based development in .NET — basically, all the software that nobody is paying money for. We can migrate parts of the Fog Shop to .NET and certainly use .NET for all kinds of internal stuff. (Today I wrote a FogShop Coupon Generator in ASP.NET. It’s kind of messy but it works!)
Second problem: the obese 20 MB CLR (runtime). It’s bad enough that about 6 MB of the 8 MB CityDesk download comes from runtimes and data access libraries; we just can’t expect every home CityDesk Starter Edition user to download another 20 MB. The hope is that in a year or two or three lots of people will have the CLR from somewhere else (too bad it didn’t make it into Windows XP). We’ll keep an eye on that; it used to change your user agent; I hope it still does, so we can get statistics.
The bottom line is that neither CityDesk nor FogBUGZ can be ported to .NET today. We will port some future version of CityDesk when the CLR has about 75% penetration. The plan is to:
- port existing code and forms using Microsoft’s conversion tools
- fix problems by brute force until it’s working again
- create new forms and classes using C#
- gradually port old forms and classes to C# whenever they need major work, anyway
- many old forms and classes will remain in VB.NET forever (using the ugly backwards compatibility string functions, etc.) as long as they work properly.
FogBUGZ also needs to wait for greater CLR penetration on server computers; we need to survey our customers and find out how bad it would be if FogBUGZ required the CLR.
We have another product in the works which we haven’t talked about publically; this one will share a large portion of its code base with FogBUGZ (a subset we are going to name “Dispatcho”) so it will remain VBScript/ASP at heart until we port FogBUGZ.
For FogBUGZ/Dispatcho/SecretNewProduct, the plan is:
- wait until it’s OK to require CLR,
- port existing “business logic” classes to C#,
- keep current web forms in ASP,
- and create new web forms in ASP.NET.
Discuss
