Give Visual Basic language apps a cloud afterlife with code conversion

Microsoft introduced the first version of its Visual Basic language in May 1991 at the Spring Comdex trade show in Atlanta. After six generations of the original product, the development platform morphed into Visual Basic .NET. Even though Visual Studio 2017 continues to offer Visual Basic -- along with the considerably more modern and popular C# language -- apps written in it long ago are best served by conversion to a modern, cloud-savvy architecture.

Tom Button is CEO of Mobilize.Net Corp., a Bellevue, Wash., cloud computing consultancy that specializes in refactoring legacy Visual Basic language programs into modern languages and structure for deployment into cloud computing architectures. If anyone understands the nuances and limitations of Visual Basic, it's Button: He is the former, longtime corporate vice president of Microsoft's developer division -- the very same guy who brought Visual Basic's first six releases to market in the 1990s. Button spoke with SearchCloudApplications about the process of refactoring old programs for the cloud age.

Do you see the .NET and Windows platforms as viable today in the cloud and mobile age?

Tom Button: Windows and .NET are legacy platforms; it's not what people are targeting today. [Editor's note: Microsoft would disagree.] We had a great run at Microsoft, building up the client-server programming model, but the opportunity now for developers is much broader than that.

What impact did the rise of the cloud computing model have on legacy programs built for client-server architectures?

Tom Button

Button: The cloud changes everything. There are millions of applications written during the client-server era that need to move. The cost of deploying and servicing those old apps is high, relative to the cost of deploying and servicing new mobile-ready apps to the cloud. The vast majority of new application development now is HTML5 front ends that are accessible by any device at any time, accessing a cloud-based back end for business logic and data access.

What about Windows Server 2016? One recent survey indicates that 87% of on-premises servers are still running various versions of Windows Server.

Button: Windows Server 2016 is one the few very competitive candidate operating systems to run in the cloud back end. People aren't writing Windows client software anymore. The days of Visual Basic are long past.

For the client side, where do you see development moving?

Button: On the client side, this class of business apps [is] almost always written in some HTML5 variant. That is the right architecture now. People can run it with a handful of different frameworks. We target a couple of them: the Bootstrap framework, AngularJS for adaptive mobile UI and the Kendo UI HTML framework.

How do large enterprises refactor an old Visual Basic language that is widely deployed with thousands of users?

Button: It's a major issue that application developers must be aware of. Customers really want to replicate the original Windows experience, because they don't want to retrain their employees or users. That's especially important when you have a network of 10,000 insurance sales offices that have all been running the same Windows app for 20 years, and now they want to get all the operational benefits of HTML5. They don't want the phones lighting up with user support questions, so they use the Kendo UI package on HTML5 to perfectly replicate the old Windows user experience.

Given your personal Microsoft legacy, when Mobilize.Net refactors a Visual Basic language application for the cloud, are you targeting Microsoft Azure exclusively?

Button: We can target Azure, Amazon Web Services or an internal data center cloud. Azure is one good candidate infrastructure, but we have customers that run on AWS. Amazon does a great job hosting Windows Server 2016, if you want to run on that.

You still see reluctance among CIOs in going to the cloud?

Button: There is still uncertainty and skepticism about running in the cloud. These companies are conservative, want to run their own operations and are not yet comfortable with the cloud, even though the major cloud players are shown to be more secure and more reliable.

Some guys want to be the last to the party on purpose, because they don't want to take the risk of being an early mover. Many companies are moving to either private or hybrid cloud-based infrastructures, but with an application architecture that allows them to move to the public cloud at any time.

What makes an old application a good candidate for refactoring?

Button: The biggest factor is what the application does and whether it has enduring intellectual property value with business logic that's been debugged over the years. Good candidates are supply chain apps that use a forms-over-data model, such as salespeople who need to get a price quote and have visibility through the supply chain.

There are thousands and thousands of apps like that written in the 1990s. They are all great candidates for putting into HTML5 so users can access them from their iPhone or Android and have the same user experience and access to the same data. Whereas before, they were tethered to their windows PCs sitting behind their desk on the LAN.

The other side is Visual Basic language apps that are not well-suited for conversion.

Button: We have seen applications in manufacturing automation that have serial cards plugged into the PCI bus to gather data off the factory floor and turn that into a programmatically accessible data set. If you're programming to the bare metal in Windows, these are not going to make a lot of sense to move to HTML5 on an iPhone or an Android.

There is no reason to reinvent the wheel just to translate from one language to another.

Also, if you have an app that was developed 20 years ago because no suitable commercial solution existed, it's probably a good idea to retire it if you can buy an equivalent application as an off-the-shelf SaaS [software as a service] offering.

When Mobilize.Net does an automated code conversion, how does the result compare to developers opting to rewrite an app instead?

Button: A developer today can write about 20 lines of production-quality, deployable code per day. Over the course of a year, you're going to get about 5,000 lines of code out of that developer. At a fully burdened cost of about $150,000 per year, that's about $30 per line of code. If you take that overseas and do it manually, those advantages are not as high as they used to be, but you might it get down to $15 per line of code. If you're doing a rewrite of a perfect model, you might cut that in half to $7.50. We target an order-of-magnitude improvement using our tools and techniques.

Developers want to work on new projects, not maintenance.

Button: Developers are never trained to deal with legacy crap; they're trained to write new code. Our message to developers is to solve new problems. Do things that haven't been done before.

What's the bottom line for developers?

Button: The bottom line is there is no reason to reinvent the wheel just to translate from one language to another; we can automate that. Compared to the 20 lines of code that developers produce daily, with our tools, they can do a thousand lines per day. For the IT decision-maker, it comes down the cost of getting deployable code.

Joel Shore is news writer for TechTarget's Business Applications and Architecture Media Group. Write to him at [email protected] or follow @JshoreTT on Twitter.