People and code: The two poles of .NET migration
2002-03-27 17:57
597 查看
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.
相关文章推荐
- Code: The Hidden Language of Computer Hardware and Software 总结
- CodeSnip: How to Get Id of the Record Using ASP.NET and SQL Server 2000
- An Overview Of The New Services, Controls, And Features In ASP.NET 2.0
- 著名的安装制作软件InnoSetup的源码及示例源码-The installation of a well-known software s source code and sample InnoSetup source
- The Secrets of Oracle Row Chaining and Migration(转载)
- The Windows SDK team is proud to announce that the RTM release of the Microsoft Windows SDK for Windows Server 2008 and .NET Fra
- How to add a Login, Roles and Profile system to an ASP.NET 2.0 app in only 24 lines of code
- Code-First Migration and Extending Identity Accounts in ASP.NET MVC 5 and Visual Studio 2013
- Guardian Overview of the LOTRO Part Two: Skills and Traits
- Announcing the Release of ASP.NET MVC 5.1, ASP.NET Web API 2.1 and ASP.NET Web Pages 3.1 for VS2012
- 【原】用使用JavaScript展开/折叠TreeView中所有节点(Expand and Collapse All Nodes of asp.net Treeview on the client with javascript)
- It is not possible to run two different versions of ASP.NET in the same IIS process:IIS
- The Building Blocks- Components of EA Part 2- Process, People, Network and Time
- give two sorted array, find the k-th smallest element of union of A and B
- Information About The Space of MFC and C#,ASP.NET
- The Building Blocks- Components of EA Part 2- Process, People, Network and Time
- Ask Premier Field Engineering (PFE) Platforms--The Slow Boot Case of the NetTCPPortSharing and NLA S
- .NET错误The 'targetFramework' attribute in the <compilation> element of the Web.config file is used only to target version 4.0 and later of the .NET Framework
- How to collect TrustZone debug logs and check the meaning of error code in the logs
- The Building Blocks- Components of EA Part 2- Process, People, Network and Time