Milan Negovan in his blog aspnetresources recently published an excerpt of Michael Feathers' book Working Effectively with Legacy Code. I liked the excerpt so much and I believe that it is so pertinent to the topic of my blog that I also will reproduce it verbatim.
--
Often people who spend time working on legacy systems wish they could work on green-field systems. It’s fun to build systems from scratch, but frankly, green-field systems have their own set of problems. Over and over again, I’ve seen the following scenario play out:
An existing system becomes murky and hard to change over time. People in the organization get frustrated with how long it takes to make changes in it. They move their best people (and sometimes their trouble-makers!) onto a new team that is charged with the task of “creating the replacement system with a better architecture.”
In the beginning, everything is fine. They know what the problems were with the old architecture, and they spend some time coming up with a new design. In the meantime, the rest of the developers are working on the old system. The system is in service, so they receive requests for bug fixes and occasionally new features.
The business looks soberly at each new feature and decides whether it needs to be in the old system or whether the client can wait for the new system. In many cases, the client can’t wait, so the change goes in both. The green-field team has to do double-duty, trying to replace a system that is constantly changing.
As the months go by it becomes clearer that they are not going to be able to replace the old system, the system you’re maintaining. The pressure increases. They work days, nights, and week-ends. In many cases, the rest of the organization discovers that the work you are doing is critical and that you are tending the investment that everyone will have to reply on in the future.
The grass isn’t really much greener in the green-field development.
--
I concord 100% with Michael Feathers. Rewriting code is something that can be achieved only at a very large rate of consumption of time and money! My thesis is that migration, specially automatic migration, is often the best option. You can easily change the platform and then focus on rewriting/rearchitecting only the pieces that truly deserve it. This has been proven over and over again at ArtinSoft.
How did ArtinSoft got into producing Aggiorno (www.aggiorno.com )? Well after more than 15 years in the software migration market we learned a few things and we are convinced that developers want to increase their productivity and that automatic programming is a very good mean to do just that.
Aggiorno is the latest incarnation of ArtinSoft proven automatic source code manipulation techniques. This time their are aimed at web developers.
Aggiorno, in its first release, offers a set of key automated improvements for web pages:
- Search engine indexing optimization
- User accessibility
- Error free, web standards compliance
- Cascading Style Sheet standard styling
- Site content and design separation
Aggiorno's unique value proposition is the encapsulation of source code improvements, utterly focused on web developer productivity in order to quickly and easily extend business reach.
At Microsoft TechEd in Orlando this tuesday June 3rd 2008 we announced the availability of Beta2 and we have included all the suggestion from our Beta1.
Download the Aggiorno Beta2 now and let us know what you think.
Aggiorno is an add-in for Visual Studio 2005/2008 that can swallow horrible non-validating markup and help you make an ASP.NET site web standards compliant with little effort. With Aggiorno web developers can improve their ASP.NET or HTML sites by making them comply with the latest web standards and incorporating the latest technology trends. This will immediately mean increased productivity and immediate business value.
Beta 1 has just been released, so you might want to give it a try and send some suggestions to the development team.
Here is an excerpt from an article that Greg DeMichillie wrote on Directions on Microsoft April Edition:
"The planned follow-on release to Windows Vista, code-named Windows 7, will not include the Visual Basic 6.0 (VB 6) runtime libraries, Microsoft has begun informing customers. This sets a timeframe for the final end of support for the runtime."
As we have informed on several occasion in this Blog, Microsoft is performing all the normal steps to retire a technology from market. Visual Basic 6 was/is a tremendously popular technology but never the less it will have to go away.
Jarvis Coffin once said: "All technologies fade away, but they don’t die." This is most probably what is going to happen to VB6 (hey.. we still have COBOL code written more than 30 years ago that is alive and kicking!!!) but the question I have for you is: will you embrace the new technology? Or will you fade away with it?
It is time to upgrade your skills as a developer and also to migrate your application to greener grounds.
ArtinSoft has been hugely successful at migrating customers as Eric Nelson (Microsoft UK DPE and blogger) recently mentioned: "Artinsoft have a lot of VB6 migration experience and can help you do the migration - either by licensing their VB Upgrade Companion or by taking advantage of their migration services. Artinsoft are doing some great work with some of my UK ISVs helping them move off VB6."
If you have any questions or comments regarding your migration strategy let's cover them in this blog.
UPDATE March 11th 2009: The title of this post was: "VB Runtime NOT in next Windows". However, Microsoft has recently updated the support policy for Visual Basic 6 Runtime. The new policy states that the VB runtime is now supported for the full lifecycle of Windows 7.
PS: You can read the inflammatory comments I got over the past week below!
The date has arrived Visual Basic 6 leaves Extended support today.
Rob Helm recently wrote on "Directions on Microsoft": "Some organizations will let support lapse on the VB6 development environment, gambling that any serious problems in the VB6 environment has already been discovered" Additionally, Rob adds: "... organizations remaining loyal to VB6 applications will have to make increasingly heroic efforts to keep those applications running as their IT environments change."
Organizations that GAMBLE with their business continuity, IT professionals that need to make HEROIC efforts to keep applications running! Don't you believe that maintaining an IT organization supporting a business is already enough of an effort to add to the mix unsupported applications?
Do you plan to be a GAMBLING HERO or is it about time to consider ways out of Visual Basic 6?
Well this might be just the right time. ArtinSoft is about to release a new version of the Visual Basic Upgrade companion. The effort required to migrate has been reduced even further and it now makes more sense than ever to automatically upgrade your applications to C# or VB.NET.
Have you been procrastinating the decision to move? Act now!!
Happy 2008!
During last year, ArtinSoft has also been working on a new product that we called Aggiorno ( www.aggiorno.com ). Aggiorno is a Visual Studio add-in designed to increase the productivity of web developers. Aggiorno helps developers with a broad range of topics like web standards, SEO (Search Engine Optimization), Accessibility, XHTML, ASP.NET, etc.
If you want to know more about aggiorno you can visit our new web site or the official blog: www.aggiorno.com\blog .
In this blog, I will continue to discuss Visual Basic Upgrades and its implications. By the way, customers are increasingly getting more excited about the speed and safety of migrations vs rewrites.
Rob Helm, director of research at Directions on Microsoft, recently answered the question "Do the new releases of the Microsoft platform have an impact on the issue of upgrading applications from Visual Basic 6 to Visual Basic .NET?" with the quote that is the title of this post.
He said that the new platform updates really do not have an impact and that you should not wait any longer to move. He emphasized that after the end of support date for VB6 the support will only be through a special support contract with Microsoft that typically is "very onerous" and increasing every year.
Additionally, Rob Helm mentioned something that I had not noticed. Did you know the name of Visual Basic .NET is now officially only "Visual Basic"? Definetely another sign pointing at the future!
Microsoft recently started to distribute a new version of the Visual Basic 2005 Power Packs.
Link to Download details: Microsoft Visual Basic 2005 Power Packs 2.0
Notably, the routines that are included help with the automatic Upgrade/Migration of VB6 to .NET. From the MSDN web site:
" Overview
The new Line and Shape controls included in this version of the Visual Basic 2005 Power Packs are a set of three graphical controls that enable you to draw lines, ovals, and rectangles on forms and containers at design time making it much easier to enhance the look of your user interface. These new shape controls also provide events such as click and double-click allowing developers to respond and interact with end users.
The Printer Compatibility Library allows projects that used the Printer and Printers Collection in Visual Basic 6.0 to be upgraded without having to re-write your printing logic. By simply adding a reference to the library, declaring a Printer and making a few minor syntax changes, your project will be able to print using the Printers collection and Printer object as it did in Visual Basic 6.0. This version adds a new Write method to the Printer object which allows you to print text without a forced carriage return similar to the semicolon syntax used by Print method in Visual Basic 6.0.
The PrintForm component is designed to bring back the ability to easily print a Windows Form. With this the new PrintForm component you can once again layout the Windows Form exactly as you want it and allow your users to print the form as a quick report."
I'd like to relate this post with the one I did a few days ago related to performance (http://blogs.artinsoft.net/fzoufaly/archive/2007/0... ). In the previous post I was arguing about the use of the VB6 Compat library from .NET applications. Basically, I was arguing that the VB Compatibility library is written and distributed by Microsoft and therefore users should not be afraid to use it in their programs. TThe same goes with the power pack Microsoft is now releasing. The power pack contains a number of functions that are not directly addressed by the basic .NET framework but that are widely used and requested by VB programmers. So what is the right solution? Well, program them in .NET!!! I mean, is there another way to provide functionality that is not by programming it? Again, don't be afraid of using these routines more than you would be of any control you use in your app. And also, do not worry about the performance hit!!
Microsoft is committed to support the vb6 runtime environment on Vista. However they will not continue to support the IDE: the development environment is not officially supported by Microsoft on Vista.
More detailed information can be found at:
VBRUN and ftponline
Additionally, do not forget to also verify the support of your third party controls. Are they being supported by their manufacturer?
Many companies have already moved or are in the process to upgrade their Visual Basic Applications to .NET. However, many others are procrastinating their decision. Which type are you? Dont'you think it is time to move yet? What are you waiting for?
A common question when upgrading VB6 applications to .NET is regarding the performance of the application.
The short answer is that the migrated app typically performs as good as the original application. Let's dive into a couple of common issues that customers typically worry about:
1) the use of the VB6 compatibility classes in .NET: First of all, I believe this is a very bad namespace name! Everytime you hear compatibility library you think about performance. However, in this case, all the classes in the compatibility library are implemented in .NET. They are included just to simplify the maintainability of the code. The functionality that they provide is not directly provided by .NET, therefore, the correct way of implementing it is to just program it in .NET which is exactly what the compat classes do. NO performance penalty here! In addition, these classes are part of the .NET framework, thay are supported by Microsoft and they will continue to be supported for the forseable future! If there is a function in there that you want to use it, just do it!
2) COM Interop: The VB Upgrade Wizard generates primary assemblies for the COM component that are referenced from VB6. This is of course the fastest way to communicate with them from .NET. Now, typically, COM components are black boxes that presumably execute non trivial functionality. This means that typically the time spent by the execution of the COM component is orders of magnitude larger than the time spent in the calling of the component from .NET. Therefore the performance impact is negligible. This is not true of course if the COM interface is very chatty as you will have to go through the primary assembly overhead many times.
The reason to eliminate COM interop is normally not one of performance. You want to eliminate COM components for maintainability reasons, for deployment reasons or to take advantage of newer versions of the components. If you just want to maintain the same functionality COM interop does not present a performance situation.
In summary and reinforcing the introductory statement a converted application from Visual Basic 6 to .NET typically performs in the same way as the original one.
Have you had a different experience? Let me know!