A friend of mine has been urging me to take on a project for him at work. His project uses a program that was written in VB6 (or even VB5) more than a decade ago. After getting a hint about its location, I delved into a dusty removable HD, and found the source code. My friend is concerned that this program, written in such an old language, may fail sometime in the next few years. It may fail because of hardware changes, OS changes, requirement changes, or something like that. Due to the archaic nature, it would be hard to simply tweak the existing code, and all the people who were associated with that code are long gone.

Frankly, I was interested in taking this on for purely selfish reasons. I know these people, we've worked together on other projects, we're friends outside of work, and the project would also allow me to stick my thumb in some eyes that have earned it. So, it would be an enjoyable project to take on. It wouldn't be terribly challenging, though, as there really isn't any inovation to add, but it would allow me to be fully immersed for a few months.

However, I fear that I shouldn't be so supportive of this idea. My friend is mostly concerned that the old project is nearing the end of its life, and is no longer maintainable. That may well be true, but it hasn't died yet, it is fully functional, and after a bit of thought, I am thinking that it is a false promise to rewrite it in .NET just to move it into a modern age.

My thinking is that VB1-3 were one language, while VB4-6 were quite a bit different (I have heard this, but I never used VB1-3, so that's second hand only). If that is the case, then VB4 was released in 1995, marking the birth of that language, and VB6 was released in 1998, marking the end of that language. Plenty of code still remains in that language, but it is fading out slowly, and would die fast if the runtimes were no longer included in the Windows OS. VB.NET2002 was followed by 2003, but then it was changed considerably with the release of 2005, and I would say that 2005, 2008, and 2010 are all interchangeable, while the earlier .NET version are not so much. I would say that because virtually any project written in 2005 can be opened in 2010 without any problem, but that can't be said for a project written in 2003, which used a different startup model.

So, if VB1-3 had a run of four years, VB4-6 had a run of seven years (until VB6 was replaced by .NET and MS stated that there would never be a VB7), the early .NET had a run of three years, and the modern .NET has been around for 5 years and counting, is there any real hope for the stability my friend is looking for? If I were to rewrite his VB6 program in .NET2010 to take advantage of the most modern version, then it is highly likely that 10 years from now, whoever is in that position will be making the same case that the program needs to be rewritten in whatever is the going thing at that time.

The Y2K crisis came about because COBOL developers in the 70s and 80s couldn't believe their software was still being used 20 years down the road. These days, writing in VB, there is a window of less than 10 years before the ability to maintain the software becomes a legacy task using tools that might be hard to obtain and not well known. It seems like the only way to create continuity is to write in some language like C/C++, which is slower for development, but also far more stable. Even that may not work, though, because a change to the OS could make even programs written in those languages unsupported.

So after that long ramble, here's the question: Is it justifiable to migrate a fully functional program into the current flavor of .NET knowing full well that the current flavor of .NET is going to be yesterdays news in a few years, or is it better to leave a working program as it is because the replacement will be, itself, archaic in a decade?