"When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work. You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years." Joel Spolsky. -- (The second NEVER in the title is mine, not Joel's!.)
I am not sure if when Joel wrote this quote (to which I profoundly agree) was thinking about automatic conversion of software. I absolutely agree that if you have a running applicatiion and you want to move it to a new platform, a rewrite from scratch is the WORST possible option. You would not believe how frequently I see this happening in my day to day work at ArtinSoft.
When you can automatically transform your source code to a new language you can have the best of both worlds.
Let me explain. With automatic conversion you maintain all the knowledge that is embedded in your current application. At the same time, you are able to move your source code to the more modern environment and immediately be able to take advantage of the new features and to effectively extend the life of your code. The cost of migration of programmers skills is also reduced dramatically by the automatic upgrade approach. What is the most difficult aspect to learn for a programmer? Is it the new language or the inner workings of an application? I would argue it is the second aspect. Programmers are very adaptable in terms of technology, but learning the intricacies of a business model supported by an application can take years! Again, the automatic migration approach allows a smooth transition for a programming team. All the knowledge they had about the application is still there. In fact, they can easily study the converted code and learn from it. It is much easier to start modifying an existing program than creating one from scratch when you have never programmed in a certain language.
In summary, Joel is right. You should NEVER throw away your code. Automatic Upgrade from Visual Basic 6 to Visual Basic .NET is an excellent option to modernize your app while maximizing its ROI.
Some comments to the VB Upgrade Guide and how to approach the Migration exercise.
Link to Getting started: Tips for VB6 to VB.NET 2.0 migration
An excerpt of the above page that I believe is important to always remember when approaching a migration:
A migration of any kind tends to face a quandary. "As long as this application is being moved over," someone will ask, "why don't we add some features?"
In organizations large and small development managers are constantly pressed to create new functionality, but the essential goal when you move an application is to create a baseline reference of the app and the development team. How long does it take to develop/migrate? What has to be done? Does it still work the same? These are questions you need to answer, but cannot answer with assurance, if your application has morphed into something new.
Said Pleas, "When you add a feature, you are satisfying somebody's need and that can be important if they have the budget." It can be difficult to focus on the objective of learning as you migrate, Pleas indicated, but that is just what is needed if you are to achieve a successful outcome.
"It is very important to separate the actual migration project from further advances, said Eugenio Pace, product manager, Patterns & Practices, Microsoft. "We have found separating the migration [from other functional development] is very pivotal."
"It is important because you now will have a baseline against which you can test. If you had a test [before in the VB6 version], the application should now perform in the very same way," he said.
Achieving a "functional equivalent" is crucial, said Fedrico Zoufaly. As Zoufaly, Pleas and their co-authors point out in their migration guide, the process that you use becomes a key factor in upgrade projects. Maintaining functional equivalence as you move into the new technology is highly recommended.
Put another way: Take something over that you know is working in COM or DCOM and then you can actually see what is needed to make it work in .NET.
Thomas, Thank you for your comments on ArtinSoft's technology.
Link to Thomas F. Abraham - On Technology : Code Conversion Tools - VB6 to VB.NET, Java to C# and more
My blog has many links towards resources that can simplify the migration process and make the CIO justification much more palatable!
You can find it on Amazon, Barnes and Nobles or all other major book chains.
I highly recommend it!
0-7356-2298-1Microsoft Press 073562298104/2006
List Price: $49.99Paperback694 pagesCD or DVD included.
Upgrading Visual Basic 6.0 Applications to Visual Basic .NET and Visual Basic 2005 was jointly developed jointly by the Microsoft patterns & practices team and ArtinSoft, a company with vast experience in Visual Basic upgrades and developer of the Visual Basic Upgrade Wizard and the Visual Basic Upgrade Wizard Companion. This guide provides proven practices to upgrade applications that were developed with Visual Basic 6.0 and reach functional equivalence with a minimal amount of effort and cost. The guide also includes guidance for common advancements after the upgraded applications are running on the .NET Framework.
It has been about 4 years and still the article that pops up first in Google when searching for "VB Migrations" is an article published in the dawn of .NET: Lori Piquet's "Abandoning the Fantasy of VB Migration Wizardry" (http://www.devx.com/vb/article/16822 ).
It is clear that the article was published to drive readers more than to provide a tool to help customers make a decision. Since I was the person who supposedly provided the reasons to demonstrate that a VB conversion was not possible and since it has been 4 years, it is about time I "defend" myself against her claims.
So, if you have read this blog, you must know by now that VB upgrades are not only possible, but they are actually a very good option for companies that wish to leverage their software assets. In fact, during the past 4 years there have been many demonstrations of this fact and corporations are doing VB6 conversions and they are quite happy with the results. With the publication of the VB Upgrade Guide from Microsoft (with strong input from ArtinSoft), the assessment tool, and ArtinSoft VB Upgrade Companion the magic is actually happening!
Lori said: "After a developer is sufficiently comfortable with .NET and has spent several weeks in studying the migration process with the tool, Zoufaly says that a migration should progress at an average rate of just 7,000 to 10,000 lines of code per week. Therefore, a 1 million-line VB6 application will take 100 weeks—two years—to upgrade. Seems a little slow for something that Microsoft had the hubris to dub a migration "wizard."".
Well, how many production quality lines does a great software developer writes per week? A few hundreds maybe? So, if there is a process that automatically allows you to pretty much rewrite your application to a new platform in a very consistent way, allows you to bridge the obsolescence gap at a rate that is more than an order of magnitude the normal rate of development? How would you call it? I think “Wizard” is not such a bad name after all. I am certainly not trying to say the process is magic and I also believe that "File-Open-Convert" from inside Visual Studio might not be the right gesture to set up proper expectations in terms of a conversion project, but it is true that the process is there and it works very well.
By the way, I am not making up the productivity statistics for software developers. The Software Productivity Research Institute (www.spr.com ) publishes such statistics and they more than confirm what I am saying.
I guess time was on my side and, today, nobody would argue about weather VB6 automatic conversions are magical or not. It is clear that there is a methodology behind, it is clear that they cannot be approached as ad-hoc projects and it is clear that they benefit customers and are less risky, and more cost-effective than manual software rewrites.
As always, I invite you to share your experiences. Don’t forget that I still have prizes for you!
Getting started: Tips for VB6 to VB.NET 2.0 migration
Another PODCAST with more information on VB migration. Your comments welcome.
Mark M. Baker
Federico Zoufaly promotes automated migration to .NET for significant investments in legacy apps. Federico also discusses the advanced ArtinSoft VB Companion tool.(MP3, 16:23 mins.)
Another POD CAST. Listen how customers have done it. And remember if you share your migration story with me I'll send you a PRIZE!
Mark M. Baker
Federico Zoufaly of ArtinSoft discusses the unique challenges in migrating large VB6 applications to .NET including a real life example of a 5 million line VB6 application that was successfully ported by a client. (MP3, 16:23 mins.)
In these pod casts you will find an interesting interview of myself talking about ArtinSoft's experience on .NET migrations. Many of the basis are covered. Please send your feedback and enjoy!
Mark Baker and Nik Hemdal interview Windows and .NET experts on techniques for getting the most out of the .NET platform.
Audio is provided in MP3 files. Listen online or subscribe to the DevNet .NET Cast feed
Mark M. Baker
Federico Zoufaly of Artinsoft discusses its Ready-Set-Go! methodology for migrating VB6 applications to .NET and how its extensive experience with migration was a key reason Microsoft selected Artinsoft to develop the VB6 Upgrade Wizard and provide key guidance in the VB6 Migration Guide. Learn how to approach migration as a systematic and thoughtful manner to ensure success. (MP3, 17:23 mins.)
Mark M. Baker
Federico Zoufaly of Artinsoft, the developers of the Microsoft VB6 Upgrade Wizard, describes the benefits of iterative upgrading -- refactoring your VB6 code each time to refine the result from the wizard. He also digs into the internals and improvements of the VS 2005 Upgrade Wizard. (MP3, 16:45 mins.)
Today ArtinSoft added a new solution to its portfolio. We are now able to provide consulting services to migrate from C# to VB.NET. This is in recognition of the broad spectrum of programmers, solutions and customers preferring VB.NET.
Share your opinons!