Bad idea. Even if MicroSoft came up with a viable *business* case to switch from VB6 to VB.Net, on a corporate level you are setting yourself up for failure when MicroSoft's *next* release of VB.Net does to the VB.net what VB.Net did to VB6 (i.e. fail to implement backwards compatibility).
To go to VB.Net from the corporate perspective (a very different bean-counting viewpoint from that of a single independent programmer), your teams have to learn an entirely new development environment, a new programming language, a new architectural paradigm, as well as give up the superior VB 6 integration with VBA office apps such as Autocad, MS Excel, MS Word, MS Access, etc. Oh, and you also lose VB 6's superior error detection and correction capabilities.
And once you get your team through all of those hurdles, your corporation has to antitcipate that MicroSoft is once again going to screw you by killing backwards compatibility again when they come out with the next release of VB.Net or its successor ("Wired.net" anyone?!). I mean, if MS killed backwards compatibility going from VB 6 to VB 7 (ooops, VB.Net), then why wouldn't they kill it again going from VB.Net to VB 8?
Essentially, MicroSoft is saying that VB should not be used by corporations, only by independent programmers who don't have much at stake (e.g. having to rewrite large amounts of legacy apps). After all, re-work for the sake of rework is hardly what project managers want to present to their corporate CIO's.
Technically, VB.Net is inferior in multiple areas (e.g. no backwards compatibility, VBA support/integration, error detection and correction) to the older VB 6, anyway. Worse, if you make the jump to VB.Net, at any moment MicroSoft is liable to screw you by coming out with a new version of VB that once again isn't backwards compatible.
Can you imagine the howls from the C++ crowd if some new version of C++ didn't support older C++ code?!
It's utter madness, yet that's precisely what MicroSoft did with Visual Basic. At a corporate level, everyone besides MicroSoft has got to get away from VB; you simply can't justify going forward with release plans that may or may not be backwards compatible in the future, much less be technically inferior to the older releases in the first place.
I found these following statistics:
Microsoft introduced VB .Net in 2000, and since then, developer use of VB6 and older versions has declined steadily. Many of those leaving the language behind are migrating not to VB .Net but to non-Microsoft languages such as Java, according to some surveys. For example, a November 2004 survey of EMEA developers by Evans Data found that Visual Basic had lost 25 percent of its EMEA developer base since 2003.
VB .Net grew from 16 percent of EMEA developers in the autumn of 2002 to 32 percent in late 2004, with 43 percent of EMEA developers using some form of Visual Basic, the survey found. About half of the developers who had used VB6 or earlier did not migrate to VB .Net Evans Data said.
In North America most Visual Basic developers continued to use VB6 and older versions 45 percent of all North American developers, compared with 34 percent for Visual Basic .NET. Fifty-four percent of North American developers used some sort of Visual Basic.
"One of the main issues keeping VB6 and earlier developers from making the migration to VB.Net is the steepness of the learning curve," said Albion Butters, Evans Data¹s international analyst, in a statement. "The difficulty in moving existing VB6 apps to VB .NET is, in some cases, insurmountable.²
I mean, if MS killed backwards compatibility going from VB 6 to VB 7 (ooops, VB.Net), then why wouldn't they kill it again going from VB.Net to VB 8?
But there does come a time when the engineers tell you that in order to do the New Thing right, they have to break the Old Thing. It's a very risky thing to do. Intel is finding that out with the Itanium. "Let's do 64-bits right. Unfortunately that means leaving x86 behind." That one will probably turn out to have been a mistake. AMD extended x86 to 64 bits, and they're cleaning up. I'm not surprised by the stats in #61. That's the risk you always take when you do this. "If we're gonna re-train everybody anyway, let's look around and see what else is out there." So you lose some to the competition. Microsoft probably had a pretty good handle on what the attrition rate would be, but they must have decided it was worth it to get where they want to go. But they won't be doing it often. They know what .NET is going to look like five years from now. There's no need to break things again for a long time. |
Sounds like a great business opportunity for someone to come in and offer support at a reasonable fee for these older development tools, if there's such a great market for it.
Unfortunately, it looks more like whining that Microsoft support will no longer be "free". But as far as I know, no decent support is.
Didn't Red Hat completely strand their users for "Red Hat Linux", without even offering pay-as-you-go support a few years ago? I don't remember much outcry then...