Columns

Jumping into .NET: Is now the right time?

• By David Chappell
• October 1, 2001

For organizations that have already created a substantial amount of software using Windows DNA technologies—ASP, COM+ and the others—moving to Java isn't a viable option. What's the business case for buying new software and retraining your developers? And how will you integrate new code with your existing Windows DNA applications? The .NET Framework provides good support for this, while Java products generally don't. Unless an organization is unhappy with Microsoft for other reasons, such as poor support, it's hard to see why moving to Java makes any sense. I will be very surprised if the transition to the .NET Framework costs Microsoft more than a token amount of their installed base.

Yet why think about using the .NET Framework at all today? It isn't even officially shipping, although a final release is not too far away. Why not just stick with Windows DNA? The truth is that for projects starting now, the choice between these two is not simple. What follows are some of the key factors to consider in deciding whether to use the .NET Framework today.

The first question is cultural: are you an early adopter? Assuming .NET ships in late 2001 or early 2002, it will not be a safe choice for some until well into 2003. Others actually like being among the first to use a new technology. If you do not have at least a bit of the early adopter spirit, stick with Windows DNA for now.

Second, what's your deadline? How soon must this application be deployed? Using .NET will slow you down initially because, like any new technology, a chunk of development time will be lost while developers and architects get up to speed in the .NET world. Once new skills are in place, development should go faster than it would with Windows DNA because of the better environment the .NET Framework will provide. Still, the costs of learning .NET are unlikely to be recouped in a single project.

Here's another key question: what's the expected lifetime of the application you're about to build? An application that will last for two years is probably quite safe to build using Windows DNA. Using this soon-to-be-legacy technology to create an application that you'll still be using five years from now is substantially riskier. Code created in today's Visual Basic will require Visual Studio 6, the current version, for updates and changes—Visual Studio.NET can't be used. While Microsoft has promised to support Visual Studio 6 for several years, that support is likely to be quite thin five years from now. Even worse, finding developers who still understand the intricacies of the COM world in 2006 will be challenging. The longer you expect an application to remain in use, the stronger the argument for using the .NET Framework to build it.

One last issue to consider is the technical level of your development staff. Visual Basic shops are probably aware by now that Visual Basic.NET is a substantially more complex language than today's VB. Some number of VB developers won't be able to make the switch, and a larger number will take longer than you'd like to do it. You can't avoid this problem by switching camps—Java is as complex as VB.NET—so you have to face it sometime. The point to keep in mind is that a more technically oriented developer will adapt to .NET more quickly than will a VB developer who is just one step above a power user. If you have a relatively non-technical group of developers with whom to work, expect the move to the Framework to take more time.

The decision facing any Microsoft-oriented development organization is not whether to move to the .NET Framework, but when. The best time will depend on culture, individual projects and staff. Deciding when to start using the Framework isn't a simple decision, but it is an important one. Make the choice with your eyes wide open.