On 2/24/06, Dave Bernard <bernard.dave@comcast.net> wrote:

>

> For every person on this planet planning or executing a complete rewrite of

> a working line of business VFP system (not a developer tool) into

> .NET/J2EE/anything, I want to ask a simple question:

>

> "What were the business reason(s) for doing so?"

>

1. Scale. Client wanted to move to gigabytes of data, and their

internal programming staff and consultants they brought in could not

develop a satisfactory app. Client invested millions in DotNet and SQL

Server, and went bankrupt. Remants of the company are back to

megabytes and back to VFP.

2. Inability to find good consultants. Having gone through a dozen VFP

developers who were dBASE refugees and should not have been

developers, company went for the magic pixie dust of Java. After

millions of dollars of development (sounding familiar?), company was

bought for hundreds of millions of dollars and entire app was scrapped

in favor of the purchasing company's existing system.

(There are a lot of developers out there who write junk for code. I

don't think VFP attracts them, especially, perhaps it's just had a

longer time to accumulate them? I've seen some pretty awful stuff out

there.)

3. Painted too deeply into the corner: I supported a client for nearly

a decade who had a legacy system written by a well-known developer

early in the VFP 3.0 days. There were no best practices then, so there

were some fairly complex work-arounds. The system was very large and

very complex, and the micro-managing, penny-pinching boss would never

authorize an hour spent to rewrite something that worked, no matter

how arcanely. After a decade of making serious money out of this

application, he got caught up with a young guy who could show him

spiffy little tricks in *Delphi* of all things (out of the frying pan,

into the fire) and, not understanding the differences between

superficial GUI tricks and the deep functionality of his application,

put his existing development into maintenance mode to go on a wild

goose chase with Delphi. He was too cheap and too wily to lose his

business to this, but his best developers quit, his customer base

moved on, and when he sells out in a few years, he'll get a lot less

than he could have.

4. Slightly off-topic from the VFP re-write question, but an answer to

why not FoxPro: Corporate standards: I tried to pitch a WebConnect app

to a Very Large Insurance Company. They had standardized on: Macs on

the desktop, Novell for their network, Oracle for their database and

Netscape Enterprise for their intra-, extra- and inter-nets. I fought

this one all the way up to a one-on-one with the CIO, who tried to

explain to me that Microsoft was "going the wrong way," a view I've

come to agree with, but for different reasons and with a differnt new

direction. IT evolution slowed to a crawl in this company, and the CIO

has taken an early retirement to "pursue other interests."

5. Cost savings: Tired of paying experienced senior developers with

decades of experience in the business niche and this particular

application, PHB thought it would make sense to employ cheap VB

developers to rewrite the app in the para-dig-m of the day, VB and SQL

Server. Experienced developers moved on, weaker devs stayed on for

free training. New apps took forever to deliver, cost gazillions, and

lacked the functionality of the original. Customers wouldn't upgrade

for fewer features. Company foundered, bought up by BigCompany for

1/10th of peak worth, for customer base. Old code and new code

discarded.

In summary: incompetence, incompetence, incompetence, incompetence,

incompetence. Hmm. Guess there is a pattern <g>.

So, Dave, you were looking for GOOD business reasons to switch? I have

run into few of them:

Good apps need to be rewritten every once in a while, as cruft builds

up, and the model of the business encapsulated in the code doesn't

always evolve as fast as the business does. Software tends towards

rigidity and/or fragility. Refactoring and other advanced techniques

are designed to extend the longevity of an application, but

refactoring a gnarly old app can be more costly than rebuilding.

When rewriting, you have the glory of starting with a clean slate, and

re-examining your assumptions. New business models (software rental,

software as a service, application service provider) may be available

since the original app was conceived (probably back when we used

floppies). ACID compliance, disaster recovery, HIPAA and SOX

compliance can make new architectures a requirement. New component

models, loose coupling, multi-phase commits, heterogenous backends are

all designs to consider.

Security is a huge concern with ever-increasing connectedness,

portability and liabilities.

So, ultimately, the business decisions come down to:

1. What business(es) do you want to be in?

2. What architectures enable that?

3. What tools enable those architectures?

4. What resources do you have available to execute those designs?

When faced with a clean slate project, new languages and tools are

always a siren song. "There are no silver bullets" is a 30-year-old

quote.

However, given the specs of a couple of apps lately, I couldn't find a

justification for writing them in FoxPro. While we have a mature

language (well-debugged, well-documented and lots of support), some

great frameworks and lots of programming talent, there were concerns I

could not address: Microsoft has handed out BILLIONs in legal

settlements in the last couple of years. Security is a huge concern

and apparently something Microsoft is still not taking seriously.

Microsoft has made it clear VFP9 is the end-of-the-road for the

binaries, with some xBase decorations extending VFP9 into Sedna.

64-bit is out and support for NX bits mean some loss of functionality.

Bottom line: a single vendor who is end-of-lifing the product.

Competing languages with rich features included Perl, Python, PHP and

Ruby had no proprietary vendor lockin, no preferred data source and

the flexibility to deploy on many platforms. VFP Web deployment is a

chain of SPOFs (Single Point of Failure): W2K3, IIS, COM. In

comparison, if a mod_perl app has a problem on Apache/Linux, redeploy

on OS X or on Zeus or via CGI. Options. Choice. That's what it came

down to. The VFP solution was climbing out onto a limb with a vendor

renowned for orphaning its products.

Orphaning: In the late 80s, I sat in a room back at the Park Plaza

Hotel in Boston while Microsoft announced the rollout of the NT

platform. During the Q&A session, a fellow came up to the microphone

and explained that he was a Microsoft "partner," had subscribed to

their products and had spent years with a staff of programmers

developing an app not far from release, but targetted at OS/2. What,

he asked, was Microsoft going to do for him? His voice was unsteady,

and it was apparent that he was facing a disasterous failure. There

was an awkward silence when he finished as the crowd fell silent.

There was no noise but an occasional clink of crystal against

silverware. A Microsoftie finally managed to speak up, trying to

deflect the comment into a pitch for their new development tools. The

spell ended, but the impression remains to this day.

I can't lead another client down that path. THAT's the business reason.

--

Ted Roche

Ted Roche & Associates, LLC

http://www.tedroche.com