"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.
---
"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.
---
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.
Monday, August 11, 2008
"Retired!" (Article: Michael Desmond)
From MCP Magazine:
Subscribe to:
Post Comments (Atom)

No comments:
Post a Comment