People and code: The two poles of .NET migration

By David Chappell

Moving to the .NET framework is a "when," not an "if," decision for most Windows development organizations. Two aspects of this migration deserve particular attention because they're likely to take the lion's share of the total effort and expense. The first is moving people: What will this transition look like? The second, which is no less important, is moving code. When does it make sense to adapt existing Windows applications to the .NET framework?

Let's start with people. There's no way around it: Every developer who will work on the .NET framework will require extensive retraining. And while there are an army of training companies out there that hope you will hire them for the task, none of them is cheap. Retraining your entire development staff isn't a small undertaking, and will not be inexpensive. The good news is that once your staff is up to speed in the new world, they should be significantly more productive. The .NET framework provides a much more consistent environment than the world of Windows DNA, and it also offers more services through the .NET framework class library. Yet more services implies more time to learn those services, so expect the bulk of the retraining effort to focus on this class library. Learning a new language is relatively easy, but learning a large new library will take some time.

Actually, learning a new language might not be all that easy. Today's Windows developers work mostly in C++ and Visual Basic, and Microsoft clearly intends these two groups to migrate to C# and VB.NET, respectively. These two new languages provide almost exactly the same set of features, so the primary factor in making the choice will likely be which syntax seems more natural. If you imagine a continuum of developer skills, ranging from the rankest beginner to the most highly technical savant, C++ programmers are all bunched up near the top. C++ is a hard language, so people who use it will have no trouble migrating to the similar but significantly simpler C#. Today's Visual Basic developers, however, are spread throughout that skill continuum. Those at the top will have no trouble learning VB.NET (in fact, they'll welcome its enhanced power). Those in the middle will largely make the switch, too, although you can expect some whining from them. But some of those at the bottom of the development skill ladder won't be able to make the switch—VB.NET will just be too hard for them. If you have a significant number of these people, prepare to hire new staff.

Moving people to the .NET framework is simple in one way: You know what you have to do. But our second problem, moving code, presents more options. Existing C++ applications will still compile with the version of C++ provided by Visual Studio.NET, so there's no immediate need to worry about migration. But existing VB6 applications can't be compiled using Visual Studio.NET; the changes to the language and the environment are too great. What should you do with this code?

One choice is to port current VB6 applications to the .NET framework. Yet I don't believe this is worthwhile for most existing code. What's the business case for doing it? Imagine requesting funding for moving a working VB6 application to the .NET framework with this (quite correct) argument: "I want to modify this app to work in the new world of .NET. When I'm done, it will have the same features as it does now, but it will run more slowly." The people who control your company's purse strings are unlikely to be moved by this kind of reasoning.

Some apps, of course, are worth porting. ASP applications will run faster on the .NET framework, not slower, and it's entirely possible to add new features, such as Web services, to an application as it is ported. But I think it will be difficult to construct a compelling business case for moving most existing VB6 applications to the .NET framework. Instead, new framework-based code can be attached to the application using the COM interoperability support the framework provides.

This means organizations will need to maintain both Visual Studio 6 and Visual Studio.NET environments for some time. Both can be installed at once on a single machine, but maintaining parallel worlds is not desirable. And while Microsoft promises to support Visual Studio 6 for a good while, it's not yet clear exactly how long this will be. Microsoft presents itself as an enterprise vendor, so this period should be measured in years, perhaps even decades. If the people in Redmond fail to understand this and drop support for Visual Studio 6 too soon, they will demonstrate that Microsoft is not the enterprise vendor it claims to be.

Moving people and perhaps some code to the .NET framework is essential, and the process is bound to be more expensive and painful than we'd like. Yet there isn't really much choice—moving to the Java environment would be even more difficult and expensive for Windows development organizations—and, in the end, the result should be worth it. As the arrival of .NET demonstrates, a willingness to learn new things is an essential attribute for anybody who wants to be successful in software.

David Chappell is principal at Chappell & Associates, an education and consulting firm focused on enterprise software technologies. He can be reached via E-mail at david@davidchappell.com.