by John Browne, on Oct 23, 2018 7:45:00 AM
Eike Michel had a problem.
The Director of Research and Development at Aucotec, in Hannover, Germany, was responsible for a 18 year old VB6 program that was a critical piece of the software products the company sold to companies like VW and Siemens.
Too much VB6
This particular piece of code--more than 150KLOC of VB6--monitored Visio while engineers created drawings and, using the Visio API, created corresponding data for object-oriented engineering CAE systems. These systems produce, for example, digital models and electrical diagrams for automobiles, plants, and transmitter stations, which turn out to be highly complex.
I talked to Eike earlier this week while he was driving through the Czech Republic.
I've never met him, but his picture from LinkedIn makes me think we could have a lot of fun together during Octoberfest. "Fräulein! Zwei Bier bitte!"
I also have to think Eike didn't look quite this cheerful a few years ago when he considered that his VB6 application couldn't talk to 64-bit Office, which meant at some point his customers were going to be upset.
So Eike did what most dev managers do in this situation: he tasked one of his senior developers to explore ways to get off VB6.
What followed is a familiar tale to us at Mobilize.Net.
Rewrite or convert?
The six engineers responsible for this product were divided about whether to convert the VB6 code or rewrite it from scratch. The younger, less experienced developers felt a rewrite was necessary. After all, the VB6 code was not really OOP, there was of course as always a backlog of feature requests that hadn't yet made it into the product, and--let's face it--no one likes anyone else's code.
But the developers who had been on the original team for many years that wrote the app--those developers wanted to convert the code from VB6 to C#, not rewrite it. The code contained many many complex algorithms that had, over the years, been largely sorted out.
In the end Aucotec decided for the conversion (not rewrite) and acquired the Visual Basic Upgrade Companion to convert their app to C# using the automated migration capabilities of the VBUC. When I asked Eike why they chose VBUC he said--and I'm quoting here--that after their evaluation of different alternatives "it became clear in a very short time that there's no real competition for the VBUC."
Music to a product manager's ears.
"Worked like a charm"
One of the challenges to migrating legacy software that's still being maintained is syncing the new and the existing. Eike's team had to merge changes every two weeks to keep the C# and VB6 versions identical, considering that major changes to the interfaces were required to maintain the communication between the new managed C# component and the other unmanaged code environment of the product.. Fortunately, the VBUC is designed for exactly this kind of continuous migration.
So exactly how did the project go? "Like a charm," Eike said as he cruised through the autumn colors outside Prague (at least, that's what I hope he was doing and not stuck in downtown traffic breathing bus exhaust). The developers liked it so much they insisted next year's budget include a plan to use VBUC to migrate the server-side component from VB6 as well.
Eike is happy to be on C#. The only way to debug the VB6 app was by logging events and mulling over the log files. Very 1975. But with C# he can attach a debugger to the external app and see what's going on in real time. They even found some previously-undiscovered bugs in the original program by debugging the migrated version.
What's next? First is support for Office 64. Next is refactoring into proper OOP patterns, adding unit tests, and putting all future feature development into the C# version. He has to keep the VB6 version around, but it will only see patches, not improvements.
