The .Net invasion is proceeding a little more slowly than expected, but the all-but-inevitable market penetration continues. Many analysts predict that mainstream development organizations that adopt .Net will do so in time to deploy their first applications in Q3 of 2003. This soon-to-be seismic shift in the Microsoft development community has yet to produce the answer to a critical question for the future of software development -- where will all the Visual Basic developers go? Visual Basic has provided a convenient on-ramp into software development for millions of developers. Microsoft found the sweet spot between providing enough power to produce serious applications and isolating the developer from some of the more messy and error-prone elements of Windows and component development. Now, much of that is going to change. With .Net, Microsoft has decided to create a development environment that continues to isolate the developer from platform-specific details, but coders will have to deal with component development. Developers will still be able to carry on without thinking about pointers, memory allocation, or how to create a Windows message handler, but they will no longer be able to ignore component design concepts such as inheritance, namespaces, and method overloading. As .Net moves past the early-adopter stage, Visual Basic developers will have little choice but to transition away from the cocoon that was Visual Basic 6.0. This impending "language shock" has led many commentators to speculate on how Visual Basic developers are going to react. Will they move to Java? Will they go ahead and make the jump to .Net and, if so, will it be C# or Visual Basic .Net? Will they demand that Microsoft continue to support Visual Basic 6.0 and let it remain a distinct development subculture? Will many simply not be able to make the transition and go find jobs in retail, where Java and C++ programmers have thought they should be in the first place? I don't presume to make such predictions. But I do think it's time to dispel three myths that have sprung up around this question. Myth #1: .Net is a radical change, so a move to Java would be just as easy
Frank E. Gillett of Forester Research asserts the following: "For VB programmers -- the vast majority of Microsoft shop coders -- the leap to .Net programming is just as difficult as migrating to the Java 2 platform. What does this mean? Now is the right time for Microsoft IT shops to reconsider their commitment to Redmond and evaluate the Java 2 and .Net platforms and tools side by side." This quote should come with a little warning tag that says: "Managers beware -- this opinion could cost you a significant amount of unexpected expenditure!" The move from a Microsoft to a Java development organisation is a major undertaking. If you are to look only at the language elements (particularly between Java and C#), you can understand where this idea originated. Certainly, the development and design skills required are similar and equally different from those required for a Visual Basic application. But many more significant factors come into play. The following is just a subset. Java development environments are nearly always more complicated
The vast array of tools available in the Java environment -- arguably one of its great strengths -- naturally leads to many new applications and utilities (application servers, IDEs, debugging support applications) that a developer must master. Each new skill has its own learning curve, even if the development is going to be done in a Windows environment. Visual Studio, on the other hand, though much altered, will feel more natural in the hands of Visual Basic programmers. They will know immediately how to set a breakpoint or use code completion features. Making multiple simultaneous transitions -- language, toolset, and infrastructure -- increases the cost and failure rate of such a migration. Incremental transition is available with .Net
Most development organisations have some serious deadlines hanging over their heads, and a few months of converting applications and infrastructure is not likely in the project plan. ASP.Net pages can run side-by-side with ASP pages and can share state management mechanisms, whereas the move to JSP is going to require a much wider conversion effort. Mechanisms for calling COM objects from C# and Visual Basic .Net have been explained ad nauseum in articles, books, and conference presentations. Integration with COM+ Services is well documented. A plethora of "From Visual Basic 6.0" material is available
It has surprised me that very few resources are available that provide a clear path from Visual Basic to Java. Although I have seen some custom training classes for this and a few books (most out of date by now), there seems to be a conspicuous absence of this kind of material. As you would expect, there's a wide array of books describing the transition to Visual Basic .Net and C#, from the perspective of upgrading both code and skill. Developers will make the transition more quickly when reference to what they know is included in training materials. I suggest the following replacement for the above myth: The move to Java is not as easy as .Net, but if you were considering such a transition, now is the time to decide. The move to .Net is the most significant transition Microsoft has asked Visual developers to make since the beginning of Visual Basic. If you have been thinking about moving to Java, it would certainly make sense to do so before you incur that cost rather than after. Myth #2: Large numbers of Visual Basic developers are going to move to Java
One of the compelling reasons to move to Java has been removed, namely that Java was light-years ahead of Visual Basic 6.0 in its ability to create large-scale, object-oriented applications. One could argue that Java is still better for this task, but at least now the question is up for debate. Before .Net, there was no question. Implementing robust object-oriented designs was all but impossible in the Visual environment. ASP was one giant kludge that often led to slow and unmaintainable code. You could write an entire book on Visual Basic and ASP AntiPatterns. Certainly most of those who were going to move to Java because of its technical superiority already have done so. Those who will take .Net as a cue to move to Java will likely be much smaller in number and will be motivated by other factors, such as vendor lock and security concerns. I think the future is relatively bright for VB developers. A percentage of developers will not be able to make the jump into hyper-speed. Visual Basic developers vary widely in their abilities and their development roles. On one end of the spectrum, they have been gluing Excel spreadsheets together and creating single screen utilities; on the other end they are writing highly distributed e-commerce applications. With some percentage of these developers, their interests, efforts, and abilities will fall somewhere between Visual Basic 6.0 and Visual Basic .Net. Perhaps retail is not their future, but they may move into more supporting roles and leave the ranks of the coders. Most of the rest will move to .Net. Myth #3: If you are going to move to .Net, you should move to C#
C# currently has the celebrity aura. It's new, it's cool, and it's hot. But other than having C-style syntax, it's essentially the same as Visual Basic .Net. Somehow this has yet to sink in. Here's a conversation I recently had with a C++ developer who is making the transition to C#: Coder: "I can't understand why anyone would learn Visual Basic .Net." Me: "Why not?" Coder: "There are so many things it can't do that C# can." Me: "Really, like what?" Coder: "Well VB. Net can't do attributes." Me: "Sure it can." Coder: "Oh, it can. Well, can it do delegates?" Me: "Yes, it can do that as well." The stigma still sticks. Dan Appleman does an excellent job of addressing this issue in Visual Basic .Net or C#...Which to Choose?, an e-book available from Amazon.com. Other than the lack of support for operator overloading and XML documentation, Visual Basic .Net has all the power of C#, plus some additional features like an always-on background compile that provides full real-time error detection that should make a C# developer envious. I submit the following alternative: Since Visual Basic .Net and C# are so similar, the decision can be made on nontechnical issues. Perception may still be a driving force in the job market, and C# is a brand-new arena for developers. Also, third-party tool support may become an issue if Visual Basic .Net gets the snub. C# may be the best choice for many Visual Basic developers, but not because of any inherent technical superiority. Getting down to the heart of the matter
With those myths out of the way, we can examine further the ramifications .Net is going to have on the future of today's Visual Basic developer. In subsequent columns I'll recount interviews with former Visual Basic developers and development teams that have made the transition to Java, Visual Basic .Net, or C#. I'll examine the cost of those transitions and what lessons can be learned to minimise the impact on development schedules and budgets. Created by developers, for developers, Builder.com brings software developers fresh, real-world perspective on topics from programming to architecture to management. Builder.com will improve the way developers work with the information, tools, and services to help them conquer the challenges they face everyday in real-world development.
For all job and work-related news, or to search for a job and get information on training, go to ZDNet Jobs. If you have something to say about work and employment issues say it here at the Jobs Forum. Let the editors know what you think in the Mailroom.
