Based on some of the messages I’ve seen on message boards and some articles I’ve been reading lately, it seems that many developers feel that the sky is falling because Microsoft has suddenly abandoned Visual Basic 6.0 (VB 6.0). The crisis that has erupted over the past month has been triggered by the “Product Family Life-Cycle Guidelines for Visual Basic 6.0” Web page (http://msdn.microsoft.com/vbasic/support/vb6.aspx) that Microsoft posted several years ago. This page defines the life-cycle schedule for VB 6.0. As it shows, VB 6.0 took its first step toward obsolescence today. Microsoft has moved VB 6.0 from the mainstream phase (i.e., is a fully supported mainstream product) to the extended support phase.
The advantage of the VB 6.0 life-cycle Web page is that it spells out what this transition means in explicit terms. The most important item to note is that this transition doesn’t mean your VB 6.0 applications will cease to work or that Microsoft no longer supports VB 6.0. It only means that VB 6.0, which is a rather old product in the technology arena, is heading for retirement.
Every product produced by Microsoft moves on at some point, as evidenced in another Microsoft Web page: “Product Lifecycle Dates - Developer Tools Family” (http://support.microsoft.com/gp/lifedevtoolfam). This Web page shows the product life cycles for all the developer tools.
I like the developer tools life-cycle Web page better than the VB 6.0 life-cycle Web page because it helps put the VB 6.0 phase change in the proper perspective. For example, Visual C++ 6.0 moved to the extended support phase in September 2004 and Visual Interdev 6.0 (aka Active Server Pages--ASP) moved to this stage back in September 2003. VB 6.0 is, in fact, the last member of the Visual Studio 6.0 family to move from mainstream support to extended support. So, the VB community has little to complain about.
However, some developers claim that, given the substantial changes between VB 6.0 and Visual Basic .NET 2002, there just hasn’t been time to properly migrate their VB 6.0 applications. These same developers seem to forget that ASP and ASP.NET are completely incompatible and there are still Web sites running ASP despite that ASP moved to extended support over a year and a half earlier.
As the grid in the developer tools life-cycle Web page shows, Visual Basic for Applications 6.0 (VBA 6.0)--the engine behind Microsoft Word and Microsoft Excel macros--will continue to have mainstream support through December 2008. This means that much of the underlying VB plumbing will continue to be maintained in the mainstream for another 3 years. And for any VB 6.0 diehards after that time, Paul Thurrott identifies a possible alternative to VB 6.0 in “REAL Software Offers Free Upgrade to Stranded VB Users” (http://www.windowsitpro.com/article/articleid/45775/45775.html).
For those who aren’t aware, I’m a Microsoft Most Valuable Professional (MVP) for VB 6.0. As such, I want to publicly state that I support Microsoft’s decision to phase out VB 6.0’s mainstream support today and phase out all support by 2008. The reason I’m declaring my support is that there’s an effort by some developers, which include some misguided MVPs, to extend the mainstream support for this old product. In my opinion, these developers are crying over spilt milk. To me, this effort is like petitioning to bring back Windows 3.1 and 16-bit programming.
I feel pretty strongly about this issue because of two events that occurred earlier in my career. It probably won’t surprise many of you to learn that I haven’t always used Microsoft developer products. Over a decade ago, I used a language called Massachusetts Utility MultiProgramming System (MUMPS). For those of you who’ve never heard of MUMPS, it was the second language ever standardized (with FORTRAN being the first). If you doubt me, check out the Web page at http://207.192.157.194/mdc/index.htm.
As a young developer, I was attending a MUMPS Development Committee meeting. In these meetings, MUMPS developers discussed how the standards should evolve. It was the height of client/server development prior to the true launch of the Internet. As part of this meeting, a senior developer stood up and said, “I’ve learned MUMPS 20 years ago. Since that time, I haven’t had to learn any new syntax or try to master any new paradigms. I like the current MUMPS implementation and think any changes to support graphical user interfaces should be measured against minimal impact.” Think about this attitude as you consider those developers asking to keep VB 6.0 as their primary development platform.
At the same time, the company for which I worked had a large product based entirely on MUMPS. The company was trying to determine how to bring this product in line with new features like GUIs that were vastly more popular than text-based roll and scroll. As part of this debate, there was a question of whether new development should continue to be based on MUMPS or should move to a SQL-based database and GUI development environment. The senior member of the technical resources department presented a detailed comparison of these technologies. This presentation focused on how MUMPS was a public standard, was supported by a robust technical community, and was a tried-and-true technology. He discussed the fact that the MUMPS technology was at the time supported by multiple vendors and, unlike most SQL implementations and GUI tools of the time, could run on a variety of platforms. He gave this presentation to a senior vice president, who made an acute observation. To paraphrase him, the senior vice president said: “Thank you for your analysis. I don’t doubt your analysis in the least and accept your recommendation that MUMPS is the best alternative today. However, the question isn’t about what you can do today--it’s about where the market is moving. In this case, MUMPS isn’t going to ever take over or even keep up with the technology market and those technologies that do will provide ever-greater capabilities than our users will demand. Thus, we will begin the process of leveraging these technologies.”
Both of these men’s past statements have helped me keep in mind that VB 6.0 and ASP aren’t solutions in and of themselves. They’re tools, and these tools are designed to help us solve specific problems. Just like any tool over time, these tools are not only wearing out but also are being replaced by better tools that allow us to do our job easier or better. Technologies will continue to evolve--and learning how to use the new tools and solve new problems with the most efficient tool suite is the business we’re in.
