According to Adams, one of the problems with .Net is that everything is called .Net--from marketing hype to Microsoft's approach to Web services architecture. I couldn't agree more. But, in addition to the confusion created by the many ambiguous dot-net labels, there's one big question that dot-Microsoft has yet to answer: What do we do with the vast army of VB6 developers?
As .Net begins to take hold in the software development arena and passes the early adopter stage, dev shops are going to have to make some tough calls.
- Do you abandon the Microsoft platform for Java?
- What will VB6 developers do?
Obviously, Microsoft is pushing hard for organizations to jump to .Net. For VB6 teams, that means investing huge amounts of time and money in training: VB.Net and C# aren't your father's VB tools. Making the move to Java could mean even more changes, from syntax differences to learning the ins and outs of Java development tools and the menagerie of Java application servers.
Some companies will seriously consider J2EE as a platform. Others will remain among the Microsoft faithful and "stick with what they already know"--even though "what they know" will change drastically. Given the flood of books and training resources available on "migrating to .Net," undoubtedly, some VB6 developers will dive headfirst into C# or VB.Net. But what about those who don't take the plunge?
Here's my take: VB6 is not going anywhere. Some pundits believe VB6 will turn into the COBOL of the 90s. Uh-huh. Funny how Y2K came and went and there are still millions of lines of COBOL out there, still running, still needing maintenance. So it is with VB6. I wish I had a nickel for every VB6 app that's running right now, from single-screen programs to complex banking applications.