Worth it to upgrade??

[wayne62682]

(Forgive me if this is the wrong area to ask this type of question.. as you can tell, I am new here )

I work for a small company that has their entire business system developed on Foxpro 2.6. However, most their hardware and software are *severly* outdated (we're talking 95/98/NT 4/ME boxes here alongside a few WinXP) and I'm currently looking at possible upgrade scenarios to pitch to management. I'm curious if it's worth pitching the idea to upgrade the Foxpro application as well, since it is over 12 years old.

I don't know FoxPro (never saw it as a viable language, to be honest) so if we were to upgrade, I'm not sure in what direction to go; upgrade to VFP (which I'd then have to learn) or try to recreate it in something more modern like .NET? I have not upgraded a Foxpro app before, and certainly never upgraded anything as old, so I really have no idea if it's even worth doing (this thing apparantly can do amazing things like take the CallerID from a phone system and use it to search a database to pull a customer's record automatically) based on the cost it will be to upgrade. It's going to be hard enough for me to convince management to even upgrade their computer systems, despite those being ancient and hole-ridden as well.

Any thoughts/ideas/experiences would be greatly appreciated. I am still in the information gathering phase right now as I look for ways to sell management on the idea of a complete infrastructure upgrade.

Thanks!

 

[wayne62682]

Thank you for your reply. I should have mentioned that it *is* FoxPro for Windows 2.6 (although there's also a DOS-based one in use, I believe). I will definatly consider moving to VFP, although I am more familiar with .NET. Thanks again.

 

[alvechurchdata]

Just to add to Mike's advantages - you can write a VFP app that will share the data files of an old Fox for Windows app. There's no fiddling with OLE or ODBC the two can just use the same files and respect each other's record locks.

This gives you the very attractive options of an incremental upgrade. You can start by just rewriting a single module or a single form and get some immediate feedback from the users as you work.

I've written a screed on this at

http://www.alvechurchdata.co.uk/foxconvert.htm

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[wayne62682]

Thanks for your comments. I am curious.. how viable would it be to just rewrite the whole thing in something else (say, VB.NET for example). I ask because there has been talk of moving away from FoxPro for the application and, given that I know nothing at all about FoxPro as a language, if we were to move away from it I'd reccomend something I can program in.

 

[wayne62682]

Hmm.. it's that hard to justify an upgrade even if something is over 12 years old?? I would imagine lack of support and severely outdated technology would be a compelling reason to upgrade a system; otherwise we'd all still be running Windows 98. Thank you for your advice, though. Much appreciated.

 

[mmerlinn]

Wayne62682[/b}

Bottom line from management's view is, "If it ain't broke, don't fix it."

Even a simple change, such as installing a new computer, can easily cost tens of thousands of dollars to implement when you consider the cost ot the computer, the cost of every program that must be updated to run on that computer, the cost of upgrading any in-house programs, the cost of getting every program on the computer to work without problems, the cost of the employee learning curve, the cost of lost customers because of computer problems, and on and on.

And that is assuming that all of the old programs have updates that will run on the new box. If there are no updates to those old programs (out of business??), one must find new programs to do the job (not always possible), write new replacement programs, or continue using the old boxes side by side with the new.

Case in point. Several years ago the water department in the city of Portland, Oregon needed to start collecting rainwater charges for the environmental department there. Instead of sending a separate bill for those charges, they decided that by putting them on the water and sewer bill, they could save money and use the carrot and stick approach to collecting charges for rain water runoff - pay them or we shut your water and sewer off.

That decision required a massive re-write of the existing program, already over 20 years old, or a completely new system, supposedly an easy choice. They chose to replace the existing computers and buy an off the shelf program from a company in Houston, Texas with added support until everything was working properly.

The result? Years and years of trying to make the program work. The software company had their people working in Portland all those years. Cost overruns of over $50,000,000. Water bills running 3 YEARS late. And finally, can the whole thing and start over AGAIN. Now 3 years after that program was canned, water bills are on time, and everything is working the way it should.

Around here, we still use an old Apple II+ (1Mhz, 16K RAM) for some things. It still works just fine for some tasks. For what we use it for it is not cost effective to spend thousands of dollars to upgrade to the latest and greatest. Newer tasks, like internet stuff, or those that could justify the costs of upgrading, are running on newer computers. If or when they no longer do the jobs needed, they will be upgraded to the next generation of computers. Most likely some of those newer tasks themselves will continue to run using outdated software on outdated machines because the upgrading costs will be too great.

From a management viewpoint, it could be much safer, easier, and cheaper to train you to maintain, and/or incrementally upgrade, the existing systems than to make any major sudden changes. Or, if needed, hire someone else to do it.

You didn't give any indication how large the company is that you work for, but it would not take a very large company to have costs run in to the millions of dollars for upgrading computers, buying new programs and/or updating old ones, etc. Is it really necessary to place yourself in the position of being fired if the whole thing goes sour and costs the company millions in lost sales, lost customers, etc?

What I would do is to find out what NEEDS to be done that CANNOT be done with existing systems. Then pitch to management to buy the needed computers, software, etc. to get that job done. Costs to do that should not be excessive, and since the job DOES NEED to be done, the bean counters will not be able to squelch the project.

One of the programs that you should pitch to management is VFP9, using the argument that the company already uses an older version in all of their current software. And pitch it even if you have no intention of using it for the job that needs to be done. You really need it on the new equipment so you can later pitch to management that they need to upgrade their old systems.

You might want to pitch .NET also, but based on your query I don't think it would be a good idea. Your company is comfortable with FoxPro and .NET comes across like changing horses in the middle of the river, SCARY. If VFP was no longer available or supported, then it becomes more scary for management to continue as in the past as opposed to changing.

Once you have the needed job done and up and running, then I would pitch management to start incrementally upgrading their FoxPro apps to VFP. That should be easy for several reasons, 1) you already have VFP9, 2) it can be done in stages, 3) the apps are already written in FoxPro, and 4) it will not cost the company lots of money upfront. If you try this with .NET, or any other language, you are going to have an uphill battle all the way, mainly because the upfront costs will be too great.

At the same time you will also want to pitch incrementally upgrading the computer systems themselves. As you well know, it is very important to management that there be as little disruption of production as is possible. The less disruption, the easier your job becomes. Too much disruption, and you will be spending more time addressing management objections as opposed to getting the company systems upgraded. And if there is way too much disruption, you may even find yourself looking for another job.

The second thing I would do is start learning FoxPro, or VFP9 if you can get it. FoxPro itself is very easy to learn - to me it feels and programs much like BASIC. VFP9 is object oriented, but since it still uses many of the underlying FoxPro commands, etc., all that is really needed is an understanding on how to do object oriented programming, which you may already have. And there is tons of help available, for example, this forum.

You are working for a company that has been using FoxPro for 12 years. From their viewpoint, they hired you to keep their systems working, not radically change them, even if they turn out to be better. And it doesn't sound to me that they are having any major problems with those systems.

Their view is, "We have been using these systems 12 years. Who are you to come in and condemn what works for us?" Your view is, "These systems are outdated and need to be upgraded." Both of you are correct. Therefore my opinion is that you need to conform as much as possible to what the company wants, while at the same time bringing the systems into this century with as FEW RIPPLES AS IS POSSIBLE. Learn FoxPro, micro-upgrade, and DON'T make any unneeded changes to their systems. In other words, forget about changing languages.

As for the viability of FoxPro, the proof is in the pudding before your very eyes.

One last thing. As for the systems being outdated and they are only 12 years old, think about this. COBOL is a 'dead' and 'ancient' language, yet COBOL programmers are in very great demand. Why? There are many many old computers out there still running COBOL programs made DECADES ago. And all of the original programmers are dead and gone. FoxPro is such a good language that you will see the same thing happen with it. Any skills you learn in VFP will still be in demand 30 years from now.


mmerlinn

"Political correctness is the BADGE of a COWARD!"

 

[dbMark]

FPW 2.6 was simply a partial rewrite of the DOS version so that it was somewhat Windows-aware, such as for screens and printing, etc. But keep in mind that FPW is long past it's supported life span. While it may work adequately on 32-bit (Windows) and 64-bit operating systems (Vista), much of its base code was still 16-bit.

One problem with FPW I encountered some 6-7 years ago was that the user had to have the same desktop screen fonts as the compiled application had or else all the application's buttons and columns were too large and bumped off screen. If one font was at 96 and the other at 120, the user started calling for tech help about missing or misplaced icons and columns.

As even more years pass, surely more unexpected issues and incompatibilities will crop up. And FPW is so old it has no MS support, just from the developer community.

Visual FoxPro is fully 32-bit and that's part of the reason it will be faster than FPW. VFP allso has a greatly expanded command set and design tools. Not to mention the last release, 9.0 SP1, was just a few months ago, not 12 years back! Microsoft makes more money on licenses for .NET and SQL Server solutions and so they push those a lot harder, especially to the corporate customers. Still, they've promised VFP support of some sort until at least 2014.

Of course, I have a friend who's an Oracle programmer and he wouldn't touch anything except his own favorite, so as much as we all try to be objective, each programmer still has preferences. And that's okay. Each project has different goals, specs, cost limits, etc.