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!"
)