On Wed, Mar 20, 2019 at 1:45 AM Kurt at VR-FX <vrfx@optonline.net> wrote:

> The second interview is coming up, it's supposed

> to be this Thursday, but I might try to postpone until Friday. Too much

> stuff going on in my life lately, including doing 2 different part time

> jobs and an extended relative who passed away recently,

I'm sympathetic to your situation, but you don't want the wrong interviewer

hearing that you're too busy babysitting parrots to interview for a job.

That's harsh, and you might not want to work for such a jerk, but you don't

want to raise red flags, or even questions, during the interview process,

OTOH, you don't want to work for jerks, either. OTOOH, they're paying

peanuts and desperate for Fox expertise. Your call,

> 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.

A 30 year's experienced app developer may have some real legacy stuff in

their app, and conversion can be a large undertaking. Along with a parallel

investigation of what the client needs the app to do is an audit of what

the application already does, Whil's Developer Guide went into this in some

detail, and I presented a series of lectures with checklists and software

for an initial audit.

So, the answer to the question on what they should do is to ask what they

want, and what they have? How many lines of code? How many tables? How many

fields? Where's the ERD? How many output documents, reports? Where does the

data come from? Where does it go? What's the IT infrastructure? What kind

of data servers do they support? What kind of maintenance windows are

allowed? Where are the users? How do they access the data: PCs, laptops on

the road, tablets, phones, embedded in other services? How responsive does

the app have to be? What happens in case of failure? What's the backup

strategy? What's the disaster recovery plan?

I suspect its also because the 1 and only programmer there, who's

> been there for like 30 years and may be retiring soon - doesn't want to

> learn something Totally new. And, also wants to minimize the transition!

>

It's likely your job is to learn everything the old Obi-Wan knows and

become the new master. Realistically (and perhaps this isn't an interview

topic), you'll keep the old app running for some time as you transition the

data model, the business model, the services model and the interface(s) to

the new platform.

> They are asking me to propose what I think is the best option.

When a consultant tells me they have the solution to all of my business

needs by replacing a 30-year-old system with whatever they are selling, on

the first meeting, sight-unseen, I would be rightfully skeptical.

The right answer is that they need to let you learn the app and research

the right solution. If you can convince them you are knowlegeable about

what is available, and what the issues are that need to be addressed in a

migration, then they should hire you to do your job.

There are a lot of good resources out there, like this list, the FoxWiki,

books, whitepapers, but you will need to do the footwork. See if you can

convince them to pay you to do that.

--

Ted Roche

Ted Roche & Associates, LLC

http://www.tedroche.com

--- StripMime Report -- processed MIME parts ---

multipart/alternative

text/plain (text body -- kept)

text/html

---

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/CACW6n4soC7hOumxVEQJE_aOfEejpYdUYerfjwPQYgG4WJj7LAw@mail.gmail.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.