It's easy for developers in North America to forget that software development is a worldwide endeavor, and that community contributions come from all over the planet. Here's a .NET Rock Star who's making a difference with no geographic inhibitions.

Jackie Goldstein has achieved national and international recognition for his expertise in Windows and .NET development in general and Visual Basic and database applications in particular. He is the principal of Renaissance Computer Systems Ltd., which specializes in consulting, training, and development with Microsoft tools and technologies. He has over 20 years experience developing and managing software applications in the U.S. and Israel, and is known for his ability to help developers understand and take advantage of new technologies.

Jackie is a Microsoft Regional Director, the founder and monthly host of the Israel VB User Group, and a featured speaker at international developer events. Jackie works closely with Microsoft in the U.S., Israel, and throughout Europe. He was chosen by Microsoft as the Microsoft Regional Director of the Year for 1999 and also received the 2004 Outstanding Regional Director Award. Jackie was selected as a member of the INETA Speakers Bureau and is the lead author of the book, Database Access with Visual Basic.NET (Addison-Wesley, ISBN 0-67232-3435). At the end of 2003, Microsoft had Jackie do a VB Upgrade Tour in ten cities throughout Europe. In December 2003, Microsoft recognized Jackie as a .NET Software Legend.

In this DevSource interview, Jackie shares his opinions on VB-to-VB.NET conversions, what's different about software development in other countries, how teams can work across huge distances, and a few tips about database programming.

DevSource:One of your areas of expertise is in migrating VB6 developers and projects to .NET. Why do you think it's taken developers so long to make the switch? What barriers do you think they perceive — and how often are those really the challenges they have to worry about? What should a software developer know, before she tackles the particular project?

Anybody making the switch to .NET, from any other platform or language, has got to be overwhelmed. There is just so much new stuff to learn — both new concepts as wells as the thousands of framework classes with all of their properties, methods, and events. I remember how difficult it was for me and other consultants or "experts" to go from knowing everything (or at least a lot) to knowing nothing (or very close to nothing). It is just a non-trivial learning curve that you have to work through; but in the end, everyone I have spoken to agrees that it was worth it and that they can now develop applications faster than they could before .NET. The language aspect is actually the smallest element — you can get through the language syntax of C# or VB in a couple of days — but then you need to figure out what to do with it!

The challenge to the VB community was greater in two different areas. First of all, the changes from VB6 to VB.NET were far more extensive than the changes from C++ or even Java to C#. I personally feel that they are all justified and good changes, and should not take that long to get a grip on. Still, there is no denying that a lot of things that we could do in our sleep, were now different. The second issue is the fact that many VB developers "grew" into VB and computer programming, rather than coming from any classical or formal Computer Science or software development training. So for many of them, learning new concepts and language constructs was more difficult. Moreover, they often lacked sufficient knowledge of Object Oriented programming, which plays such a central role in the .NET Framework classes.

Perhaps even more fundamental is, "If it ain't broke, don't fix it." A lot, a lot of VB6 developers were being very, very productive and building great apps with VB6. For many decision makers, it was hard to understand why they should make the significant investment in training and getting over the .NET learning curve — even if this was somewhat short-sighted, and indicated a lack of understanding of the benefits of .NET.

Finally, I think that there was a problem of expectations. Developers who had been working with VB over the years were used to upgrading to new versions. But what this meant in the past was usually just to re-compile in the new version and maybe make a few minor corrections to the code. Moving to .NET, of course, is a whole other story. There is no way you can just take an existing VB6 application and recompile it in .NET and expect to run; it won't even fully compile. Even after using the VB6 Upgrade Wizard to handle many of the changes, it still only does a significant, but far from complete, job of upgrading your VB6 code. You will still need to make a lot of manual changes. How much additional effort will depend on the type of application and the style of the original VB6 code.

What should be done about it? Last year Microsoft contracted me to do a VB6 Upgrade speaking tour. I developed the content, and delivered it in ten cities throughout Europe. To me, upgrading from VB6 to VB.NET is not just how to run the VB6 application through the Upgrade Wizard. In fact, that is almost always not what you want to be doing. I have three basic principles on upgrading from VB6 to VB.NET:

• Upgrading VB6 developers. This is step one: to upgrade developer knowledge and skills to VB.NET and .NET in general.
• Upgrading VB6 applications. This is a separate, optional task, and should only be started after you have upgraded your developers.
• If you want to upgrade existing applications, you should not, and can't possibly expect to, do it in one "big bang" run of the Upgrade Wizard.

There are a few important points here. The first is that "Upgrading from VB6 to VB.NET" is composed of two separate, albeit related, tasks, that of upgrading developers and that of (maybe) upgrading existing applications.

The second point is the one that I think is the most misunderstood issue and the one that causes the most fear and hesitation: You just don't upgrade existing production application en masse to .NET. You must first do both a business and a technical analysis of why, when, and how to upgrade your existing application piece by piece. I dedicated a lot of time on the speaking tour agenda to the various considerations, options, tradeoffs, and architectural approaches to this.

Sometimes, though, it still takes people time to "get it." You'd be amazed at the number of conversations I have had with potential clients who want me to help them convert their entire, massive, VB6 applications to .NET in a matter of weeks. I had a situation where Microsoft sent me in to a major ISV who had two different applications, each with over a million lines of VB6 code. They wanted me help them convert each one to .NET in 2-4 weeks! They refused to listen to me when I said they needed to do it in stages. We even started developing a plan on how we might prototype the conversion process so that we could do the actual conversion in a (ridiculously) short amount of time. When I followed up after not hearing back from them for a while, it was gratifying to hear that they had given up the idea of converting the entire application, and had taken my advice of starting to gradually add new functionality in VB.NET. I may have consulted myself out of a lucrative engagement, but I will always advise my clients to do what is really the best thing for them.

I think you will see a lot of investment and effort from Microsoft to help educate and support VB6 developers to make the move to .NET easier and quicker. It will not only be in the form of technology and tools, but also in the form of real (not fluffy) guidance. I'll be working with Microsoft to take what I have already done, and elaborate upon it based on what we have learned from the field and some of the changes coming in Whidbey.