>I have been contracted to assist a company migrating thier VFP appliation to use a SQL Server 2000 backend. They have 300+ users, and 3 programmers. The application has around 100 tables (some of which of course are 'static') and probably around 150 forms, maybe as many reports.
>
>Well, the current application uses no local views at all, and no framework was used. Needless to say they are experiencing a lot of table coruption, hense their desire to goto SQL Server 2000 backend.
>
>What I see needing to be done is to completely re-write the whole application. Use a framework this time, and a bunch of remote views, etc, and put the business rules in a COM object.
>
>My problem is that the 'lead programmer' there seems to be fighting me on this. What he wants to do is to move one table at a time from VFP to SQL, then rework each form and report that uses this table. He's willing to admit that this will take 'a little bit longer', but trying to talk him out of this idea is like talking to a brick wall. His claim is that there are too many changes happing in the old application and it would be 'impossible' to keep track of this information so it could be done in a 'new application'. I naturally brought up the concpet of maybe documenting these changes as they happened somewhere, and his response is "never done that, never will". I think this is f---ing nuts, they're going to be rewriting the same reports and forms over and over dozens of times! Plus this doesn't seem like a very 'stable' situation to have the data in either.
>

>Which brings me to what I need advise on.

---

>1. Am I right about redoing the whole application? (Obviously I think I am)

It probably wouldn't be that difficult or time consuming to rewrite within a framework, particularly if you go with a commercial framework like Mere Mortals or VFE. The lead sounds like he's taking his estimate of the beginning time/cost of the project and projecting it across the whole process, rather than seeing the big picture. Something like: it would take, e.g., 2 weeks to get up to speed on the framework, w/o having actually converting any forms - in which time he thinks, e.g., 15 forms could be done, which may be absolutely correct. This makes his timeline 20 weeks, all things being equal.
Once up to speed on a framework. These same 15 forms could be done in a week, making your timeline 12 weeks (2 for framework, 10 for coding).

He may have already thought of this, since he has said it could take a little longer. However, especially going with remote data, some of this "little longer" is going to be caught up in rewriting data connection code for each form. However, across 150 forms, this will be a nightmare to maintain - even if all the code is always the same.

He's probably also thinking quite a bit about job security - if it's takes time to program, it must be hard, so he feels indispensable. He is not necessarily correct in this, but it's an emotional issue, not a logical one.

---

>2. Assuming I am, I've got this programmer telling the guy who's paying me (his boss and VP of the whole company) one thing, and I'm telling him something different, so how the heck to I convince this VP that I'm right? All he is worried about is 'what is safest, and best for the company' and has no computer programming knowledge at all.

For the VP, you could do up a project plan w/ timeline like I've mentioned above, w/ costs, comparing the process of doing each form individually and the process of using a framework. Being a business thinker, he should appreciate that the time taken at the beginning of a project does not necessarily translate to the overall time to complete the project.

You should also bring into this project plan the already planned new technologies, SQL Server, e.g., that will have to be learned by programming staff and mastered by the lead programmer. That should satisfy the lead, too.

If it doesn't, there's probably a happy medium between full framework, and data access code only mini-framework.