How to prevent your code from becoming obsolete?

Question

Some programmers here have been developing a project in VB6, and they say they now need to upgrade to vb.net if they want their apps to run on newer/future systems as vb6 is going to be history soon.

So there is this huge application they have been working on that they are going to have to rebuild from scratch (they tried to use the upgrade wizard but there were too many errors)

The owner of the company is not too thrilled about investing so many hours in a project just to have to turn around and redo it from scratch.

This isn't my project and I don't know anything about vb, I am a web programmer.

But what can these guys do, so that this doesn't happen again, or what should they have done so that this wouldn't be an issue now?

Is there some way to make sure your application is always scalable and wont become obsolete and need to be re-written?

Thanks!

Answer 1

Considering the fast evolution of technologies arround programming, becoming obsolete is part of the normal cycle of live for our applications.

I don't really know for desktop/server applications, but, in web-development, we say that 5 years is long, for instance ^^

Of course, it is possible to update, patch, correct, fix, whatever... But doing so generally tend to degrade the quality of the code and the quality of the application itself -- meaning maintenance will cost more and more as time passes ; in the end, re-writing everything will probably mean spending less money in maintenance.

Answer 2

Nope, there's nothing around it really, although Windows 7 can still run DOS programs, so it's not like their programs will be un-runnable. The biggest problem they will run into is no new support or new features, and a shrinking community of knowledge on the subject.

My company is currently running programs in Fortran, Clipper, VB6, and FoxPro to name a few, some of which have been around for over 20 years, and have survived all of the Windows upgrades unscathed. Usually the thing that renders an old program unusable is the inability to recompile the program to fix bugs.

It certainly helps though to break the functionality of your programs up so that if you do decide to migrate from VB6 to VB .Net it's a lot easier to pick out the reusable code.

Answer 3

Excellent question.

The short answer is No. Because all code will eventually become obsolete.

If you wrote code in x86 assembler then it would last a while. C code would have a long shelf-life too. But the problem comes with the more a technology is abstracted away from assembler the shorter its shelf life due to many factors.

Answer 4

Don't focus on code that cannot be obsoleted. It is rare that you work in a stack that is applicable. Instead, make your code clear and concise so you can migrate it when the time comes. Instead, focus on not letting yourself become obsolete. Work on staying current and know what is happening in your stack and try to be aware of what is going on, even if you cannot dedicate time to fully apply yourself to it.

Considering emulation and virtual machines, I have the feeling that "legacy" code will actually have an even longer life than imagined before. It is more the tooling, as opposed to the OS anymore, that you should be concerned about.

Answer 5

It depends (perhaps) on separating code from design especially in web applications which are often highly subject to the vagaries of fashion. But is the code base is runnable on the current technology, i.e. the OS will still run it then there is no reason to "upgrade".

The real way to ensure your code lasts forever though is to write an application that becomes so indispensable in use but so expensive to rewrite that everything, including not obsoleting OS and hardware is done to ensure it keeps running. I believe one example of this is some core systems in the US Social Security / Governmental arena are still running written in early 1960's COBOL and running on old IBM mainframes.

Answer 6

As other have said, it's not "how can my application not be made obsolete." It's more "when my application becomes obsolete, how can I recover quickly." And really, that's just a different version of other questions:

• When the new version of X comes out, how can I use the new features?
• When the business rules change, how can I make changes to the application?
• When this application over here wants to access the data, how can I expose the data quickly?
• When the client wants to change from a thick client to web client, how can I give him the new platform?

This is what OO and SOA was attempting to answer. Build lots of small independent applications, and loosely couple them together using a standard mechanism. When you need to upgrade for whatever reason, pull it out, upgrade, and plug it back in.

Answer 7

I'm not aware of any recognized method for preventing the obsolescence of an unmaintained application.

If you want to prevent a product from becoming obsolete, then design it to be upgradable.

In .NET, at least, you have many, many options for creating reusable components:

• Separate assemblies, which can be used in any .NET project, and can be later extended to support COM interop if the need arises to use a different technology.

• Web services; these can be exposed publicly and used from almost any environment.

• Interfaces and Inversion-of-Control can be used to support freely-interchangeable components, which could theoretically be coming from something that isn't even .NET (just build a COM wrapper);

• Inter-process communication - if all else fails, you can literally just create a memory-mapped file or named pipe and start funneling in data from (or destined to) a brand-new application.

In fact, a number of these things probably apply to your current VB project. There are usually a myriad of different methods of extending the useful lifetime of an existing product while gradually transitioning the core functionality into a new technology.

I'm not hardcore SOA, but this is precisely the kind of problem that SOA tries to solve. I do a lot of services - in fact, almost everything significant here goes through some kind of web service at some point - and I feel quite comfortable knowing that I can completely rip out a service at any time and replace it with a service on a different platform. All it has to do is spit out SOAP or JSON and my .NET Clients can still consume it. Or, alternatively, if I need to replace the clients, I can just hook into the rich domain model that already exists in the services.

In fact, I've already done this - the architecture used to be built entirely atop a Delphi 7 platform. Now it's all on .NET 3.5, and there was never really any hard cut-over from one system to the next. We started building plain SOAP services, then moved a lot of the in-application business logic to the services, and eventually, when the application wasn't much more than a shell, we replaced it with several .NET Clients (there are a few separate applications) and then started adding various security features and optimizations that could only be supported on newer platforms. And so on and so forth.

So it definitely can be done, if you plan ahead. Of course, there are a number of people here who will advise against planning ahead, citing YAGNI... and maybe that's true, for certain projects. It all depends on just how expensive/mission-critical the project is. If the product needs to last for 50 years, then you might want to think about investing in some solid architecture and design that makes it easy for you to add and remove subcomponents.

Answer 8

They should ask themselves why they thought it was a good idea to write this project in VB6 to begin with! Didn't they know it was already unsupported and obsolete? If you start off using obsolete technologies, what can you possibly expect?

They should also consider improving the structure of their VB6 code and making it more object-oriented. That will make the transition to .NET easier. Among other things, they could try separating functionality out into external classes accessed through COM. Those same classes could then be accessed from VB.NET. Additionally, these smaller pieces might be easier to migrate.

Answer 9

The best way is to use cross-platform development tools and libraries. That way Microsoft can't deprecate things that you depend on (as they don't control them). If you depend on anything specific from a single vendor, its likely that they will screw you over at some point.

Answer 10

Open-source it, or at least build on an open-source platform.

I don't know any proprietary systems from the 1970's that we're using in a manner compatible with their old usage, but I know many open-source ones.

It's not a perfect mechanism -- all languages change, however slightly, on these timescales, and then you have to make upgrades to your code to get the newest stuff. But I know plenty of servers running code that's been around for decades with no changes.

Better yet, open-source it, or as much as possible. Even better than being able to do nothing is being able to do nothing while other people update it for you. It takes work to get the community started, but once started they can be hard to stop!

The utility of any non-open-source program drops to zero after finite time. It's no guarantee that open-source will cause it to remain nonzero, but there's at least a chance.

Answer 11

Don't use a proprietary language. Sure the libraries and platform may change, but it's interesting that the language itself has become obsolete. Stick to C, C++ or anything with a large user base that is open source. These are likely to be around for a while even if the maintainers stop supporting it - this means Python, Ruby, Java, and possibly C#. My crystal ball isn't so good outside of C and C++ but there are compelling reasons for one of the others to last 20-50 years.

Visual Basic was fun, but the intermixing of code and UI that it promotes is terrible from an architectural point of view. A good design should make it feasible (not necessarily super easy) to change backend, GUI toolkit, and OS.

You're kinda stuck with a language, so pick one that isn't restricted to one vendor who is constantly changing it.

Try reading Fire and Motion by Joel.

Answer 12

Write to standard (ANSI or ISO, I'd avoid ECMA) definitions that are currently in serious use. Avoid anything dependent on one company, or where the only full implementation comes from one company. Don't use vendor language extensions. Be careful to avoid assumptions about the language, such as data type size: if you use int to hold memory sizes rather than size_t, you may make it more difficult to run on a 64-bit system.

Remember that Microsoft is remarkable among companies for preserving backward compatibility, and they broke VB6 for you. Any other company will likely be worse.

In any significant applications, there will be parts that depend on the platform. Segregate them, to limit what has to be rewritten if the platform changes.

Obviously, there's costs in this. I've recommended, for example, that Windows applications be done in Visual C++, with MFC used through an abstraction layer, since C#, .NET, VB.NET, and F# don't qualify under my criteria. However, this is how to create a long-lasting program, if that's your goal.

Answer 13

I must have missed this question in February, sorry. As far as I can see no-one has addressed your colleagues's conclusion that they are going to have to rebuild [their VB6 app] from scratch in order to migrate to .Net.

This is wrong: they don't have to rewrite, there are alternative methods and they are usually far easier and cheaper than a full rewrite.

Here's the official advice from Microsoft UK:

Performing a complete rewrite to .NET is far more costly and difficult to do well [than converting] ... we would only recommend this approach for a small number of situations.

From a blog post by a Microsoft guy who consulted on rewrites:

Many companies I worked with in the early days of .NET looked first at rewriting driven in part by a strong desire to improve the underlying architecture and code structures at the same time as they moved to .NET. Unfortunately many of those projects ran into difficulty and several were never completed. The problem they were trying to solve was too large. [This is the point where your colleagues would be in serious trouble with their boss - people get fired at this point]

Tell your colleagues to check out the Microsoft UK advice with a screencast explaining the 5 basic options for VB6 -> VB.Net migration. They should choose the way forward in conjunction with their boss. It may be rewriting, but they should go into it with their eyes open.

And they probably shouldn't write anything else new in VB6...