In-Depth

Retired!

• By Michael Desmond
• May 2, 2007

David Lambert is one of the millions of Visual Basic programmers around the world facing a stark choice. An independent consultant and former on-staff developer at Random Lengths Publications in Eugene, Ore., Lambert relied on Visual Basic 6 (VB6) to build the company's subscription system and other services.

But when Microsoft ended mainstream support for VB6 in March of last year, Lambert knew he was in trouble. Microsoft will continue to offer fee-based extended support for VB6 through 2008 and it promises working Windows run-times through at least 2016, but none of that matters to Lambert. Unable to rely on updates to the tooling, and facing a dwindling stock of active developers to work with the legacy code, he opted to move his projects to C#.

"That was really a tough decision, because I had long-term skills in Visual Basic," Lambert says. "It's helpful knowing [Microsoft is] going to continue to support the VB6 runtime, but at the same time they're not going to assuage my fears that I'm going to have to eventually rebuild this project."

Peter O'Kelly, research director at Midvale, Utah-based research firm Burton Group, says the experience of the VB6 developer community is hardly a new one.

"I think this is a pervasive problem that has been going on ever since the second programming language appeared," O'Kelly says. "Over the last 40 years every company has gone through this. We had machine language move to assembler, then assembler to 3GLs. And we had everyone move from 3GLs to 4GLs."

.NET Killed the Programming Star
Visual Basic isn't the only high-profile programming language to earn the axe. Microsoft announced two months ago that Visual FoxPro 9 would be the last supported version of the data-savvy dev platform. That same month, Microsoft announced it was retiring Visual J#, the Java-like programming language introduced soon after the launch of .NET Framework 1.0 back in 2002.

All three retirements, O'Kelly says, are the result of the expanding and maturing .NET platform strategy at Microsoft.

"There's another theme here that's consistent across VB6 and FoxPro and Visual Studio as well. It's not just the language, it's the application model that goes with it. The language is almost incidental at that point. What you're really betting on is the .NET Framework."

O'Kelly points out that Visual Basic 6, Visual FoxPro and to a lesser extent C++ are being replaced by tools tuned for the managed code environment of .NET. "It's not Microsoft picking on the VB6 and FoxPro guys, it's that the industry has really moved on for productivity and robustness reasons, and Microsoft isn't doing this alone," he says.

The idea that the retirement of FoxPro is part of a larger strategy offers scant comfort to Bruce Allen. He's a longtime FoxPro developer who bristles when asked about Microsoft's decision to retire the uniquely data-centric FoxPro platform, which has its roots in the dBase database management application.

"It's become less about individual productivity and more about what platform are you producing on, and then standardizing on that platform," Allen says. "Ninety percent of the developers that I've known for the past 15 to 20 years, companies are hiring them to do something with data. We wanted something better, not something different and harder to work with.

"FoxPro got caught in the mix because it was kind of the dessert topping, floor cleaner product," Allen says. "It didn't clearly fit into the developer realm and it didn't clearly fit into the end-user realm.

Allen, at least, saw the writing on the wall. He switched over to coding in C# and VB.NET, though he continues to use FoxPro for certain projects and as a prototyping tool before casting code in .NET.

For Lambert, the realization that his VB code was poised to be orphaned came as a surprise. "At first I didn't really see the signs when Visual Basic.NET 2002 came out and the first .NET 1.0 came out," Lambert recalls. "I didn't realize until I saw a seminar that I wouldn't be able to upgrade my [VB] version 5 to it. When I first realized it, it was really a stomach punch."

Microsoft Program Manager for Visual Basic Jay Roxe says his team worked hard to keep the developer community fully informed about VB6.

"When we announced the .NET Framework back in 2000, we laid out the roadmap for Visual Basic at that time," Roxe says. "We told people what was going to be happening, what the support lifecycle was, and when and how we would be working with developers to move forward."

Strategies for Moving On
For all the advance warning, the retirement of Visual FoxPro and Visual Basic has kicked off something of a code crisis among development shops, which must ensure that vital applications stay relevant.

It's a major task, says Allen. "To me, VB6 is the COBOL of the 21st century. There's a trillion lines of it out there and trying to replace it is going to be a huge, monumental thing."

So how are developers adapting to life after VB6 and FoxPro?

On the Clock

Visual Basic, J# and Visual FoxPro may not be the only developer-related products heading for the boneyard. The .NET strategy has begun putting the squeeze on another well-known Microsoft technology. "I think we should talk about Visual Basic for Applications (VBA)," says Burton Group analyst Peter O'Kelly. "I think the writing is on the wall for it too." "You just can't build the level of robustness and secure code if you're writing stuff going over the Internet," he adds. "VBA is like the VB6 of embedded applications. And that's kind of unfair to VB6." Microsoft Program Manager for Visual Basic Jay Roxe says there are no plans to retire VBA. But he also points out that Visual Studio Tools for Office (VSTO) and Visual Studio Tools for Applications (VSTA) offer the benefits of .NET -- including managed code, better security and object orientation. "In the case of VBA, when you hit the ceiling, when you hit something VBA couldn't do, you were stuck," says Roxe. "With VSTO and VSTA we wanted to make sure developers never hit that ceiling." -- M.D.

"They're adopting one of the .NET languages, either Visual Basic 2005 or C#, depending on their preference," Roxe says. "We're seeing developers maintain applications with Visual Basic 6, but extend them with Visual Basic .NET 2005, and do new development in one of the .NET Framework languages."

That's the approach Lambert has taken. He tries not to touch the existing VB6 code, instead making changes at the data layer, if possible. Still, it's been a frustrating experience. "Other than a rewrite, there are no good answers. A rewrite is an expensive answer."

Jeffrey Hammond, senior analyst at Forrester Research Inc., offers a blueprint for managing the migration into .NET. He authored a paper in March that explores how to move code forward from VB6. In the paper, Hammond urges development managers to "triage their applications" and then commit to migrating, rewriting or replacing each one, based on what the assessment finds.

Hammond breaks the process into a four-square box, which helps managers plot their decision making based on the relative business value and technical health of the affected code. As shown in Figure 1, business-critical code (in the upper two quadrants) must be updated, whether via migration or a wholesale rewrite. Commodity applications can often be replaced by packaged solutions or simply left in place, depending on the quality of the code.

According to the report, well-structured and designed applications lend themselves to an automated migration process, using tools like Fujitsu CoolCat and Infosys VB Migration Workbench. Many applications, however, require significant manual tuning or even a full rewrite.

In all cases, Hammond stresses a phased approach, where applications and application modules are assessed and re-assessed as the migration effort proceeds. A collection of code that earned a deferral in the early stages of the process might two months later be targeted for a rewrite. To avoid scope creep, he suggests stabilizing the code base first on .NET Framework 2.0, then extending functionality from that point.

Jeffrey Atwood, technical evangelist at Point Richmond, Calif.-based Vertigo Software Inc. and author of the popular Coding Horror blog, says the .NET Framework offers an attractive shelter for developers worried about code thrash. He points to the large and growing community of .NET -- aligned developers and resources as a key benefit for managers waiting on a decision.

"The framework is going to be strong for at least eight to 10 years," Atwood says. "With .NET we are well past the early adopters and are getting into the midlife of [the framework]. I think this is reasonable time."

[click image for larger view]

Figure 1. Forrester Research Inc.'s four-square approach to migrating into .NET offers a useful framework for deciding how to manage orphaned code.

Coke or Pepsi
Henry Ford famously quipped that buyers could have any color Model T car they wanted, as long as it was black. With the retirement of VB6, Visual FoxPro and J#, Redmond has tightened the circle of development platforms. Beyond C++, which O'Kelly says remains crucial for performance-tuned applications, the bulk of Microsoft's development tools now target the managed code environment of .NET.

The problem, Atwood argues, is that Visual Basic under .NET is a flawed language that suffers from Microsoft's attempt to make it resemble VB6 while conforming to the object orientation at the core of the .NET Framework. The result is that Visual Basic .NET occupies what Atwood calls a "no man's land, where no one [is] happy with the product." What's more, C# and Visual Basic .NET share so much in common that they're more alike than different.

"They've made Visual Basic as close to Visual C# as I think they can get it," says Lambert. "The people I talk to anyway, think it's six of one, half-dozen of another."

"It's almost like Pepsi and Coke. Is that really a meaningful choice?" Atwood asks. "I really love Basic. I grew up on Basic. I've been using it since I was a kid. But you have to be a pragmatist. So I say go C#. And again, it really pains me to say that, because I love Visual Basic."

Slow and Steady
If you're a Visual Basic or FoxPro shop, should you be rushing for the exits? Maybe not, says Hammond, but you should at least be putting together an exit plan. Develop a process to review, score and migrate your existing code. Begin assessing alternative languages and development platforms. And start the process of cross training your personnel.

For his part, Roxe says he understands why Visual Basic and Visual FoxPro developers might be upset. He says Microsoft will continue to work to address their concerns.

We have to be very transparent with people. We're a part of the community, we're not separate from it," says Roxe. "We always try to make sure there's a path forward for the code and the skills developers have accrued over time."