On Mar 20, 2019, at 6:28 AM, Ted Roche tedroche@gmail.com wrote:
It looks like UCLA really wants to move away from Foxpro, as they know it's a dead language. But, they want to move to something similar to VFP.
And that's why they are hiring you. I you have an answer during the interview, you'd be jumping the gun. "If all you have is a hammer, everything looks like a nail." Your job should be to learn the app, learn what it interfaces with, what it gets for inputs and what it needs to output (PDF, JPEG, XML, JSON, CSV, EBCDIC?) and determine the optimal tool to do all of that and hopefully minimize the transition. It may be really easy to migrate the app to FoxXYZ, but if that can't do what they need, that's useless.
I would echo everything Ted brings up. A 30-year-old app will have many layers of functionality, and probably does a bunch of things that most people who use it don’t know about, but one or two people absolutely rely upon.
The main perspective I would add is that you should ask them if they want to keep it as it has been, or if they want to create something that will last for the next 30 years. During my career as a consultant, there were many times that I was brought in to make a particular change the customer wanted. Instead of just saying “Sure, I can do that!”, I would probe a bit. I’d ask them *why* they feel they need this change. I would ask them if there were any other parts of the system that they felt didn’t do just what they needed. Once you get them talking, listen! They thought they knew what they wanted, but almost always I was able to discern their true needs. When a plan to implement those needs was presented to them, they were usually so excited that any questions about my rate were forgotten.
And I’m sure you know what I’m going to suggest next: if they truly want an app that will take them through the next 30 years, don’t keep it in VFP. If they think finding people who know VFP is hard now… well, the situation isn’t going to get any better over time. And it would be unethical for you to advise them on a path that may be good for you but hurt them in the long run.
To sum up: tell them you will need to take the time to learn just what is needed from the app, both in current functionality and future capabilities, and then and only then could you suggest a path forward. That path should involve a programming language (or languages) that have a strong likelihood of being active for the next decade or two.
Take this as a personal opportunity to learn and grow your skillset. I never get tired of learning a new language or a new way of doing things. That, to me, is the hallmark of a true developer.
-- Ed Leafe