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
On Mar 1, 2006, at 9:12 AM, Ted Roche wrote:
> I can't lead another client down that path. THAT's the business
> reason.
Touché. My sentiments exactly.
-- Ed Leafe
Author: Peter Cushing
Posted: 2006-03-01 10:31:01 Link
Ted Roche wrote:
> IT evolution slowed to a crawl in this company, and the CIO
>has taken an early retirement to "pursue other interests."
>
>
I thought it was to "spend more time with the family"
or in David Blunkett's case "to spend more time with someone else's
family" :-)
</UK humour>
Peter
Author: MB Software Solutions
Posted: 2006-03-01 10:42:07 Link
Ted Roche wrote:
>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.
>
>
But would the investment in SQL Server have been contributing to this
failure?
>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.
>
>
I've heard this many times before...and even been part of it on the
reverse side, where we had a decent VFP app and the company that bought
us scrapped it in favor of VB6 and classic ASP (and took 3 times as long
developing it only to not have it anything close to what we had).
>(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.)
>
>
Regrettably, I've seen my fair share of bad coding as well, and some in
applications where they sell the app for $300k....yep, I couldn't
believe it. A $300,000 piece of crap that was hemorrhaging from every
orifice. Just another reminder that certainly I should be able to be in
business providing solutions if this is the kind of crap that was
selling out there. <g>
>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."
>
>
How many years ago was this one? Seems like a "dated" example?
>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.
>
>
And for some reason, folks not in the know (PHBs, owners, mgrs, etc.)
don't seem to get that. They think of the house analogy that gutting
the inside of the house HAS to be cheaper than bulldozing it and
starting over.
>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.
>
>
VFP9 will work in Windows Vista, though, and I isn't that 64-bit supported?
>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.
>
>
Logical thoughts. I'm not saying I agree 100%, because I have no
problem building a VFP application now and supporting it for the next 8
years.
--
Michael J. Babcock, MCP
MB Software Solutions, LLC
http://mbsoftwaresolutions.com
"Work smarter, not harder, with MBSS custom software solutions!"
VFP will run in 32 bit computability mode in Vista. They have stated
repeatedly that there will be no 64 bit version.
MB Software Solutions wrote:
>> 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.
>>
>>
> VFP9 will work in Windows Vista, though, and I isn't that 64-bit
> supported?
--
Richard Kaye
RFC Systems
Voice: 973.761.0868
Fax: 973.761.4329
For the fastest response time, please send your tech support
queries to techsupport@rfcsystems.com
---------------------------------------------------------
---------------------------------------------------------
Author: MB Software Solutions
Posted: 2006-03-01 11:26:24 Link
Richard Kaye wrote:
> VFP will run in 32 bit computability mode in Vista. They have stated
> repeatedly that there will be no 64 bit version.
>
There will not be a 64-bit version of VFP, yes, I knew that, but the
fact that it runs on Vista is fine for me.
--Michael
--
Michael J. Babcock, MCP
MB Software Solutions, LLC
http://mbsoftwaresolutions.com
"Work smarter, not harder, with MBSS custom software solutions!"
Author: Stephen the Cook
Posted: 2006-03-01 22:18:16 Link
Ted Roche <> wrote this on Wednesday, March 01, 2006 8:12 AM:
> 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.
True.
Stephen Russell
S.R. & Associates
Memphis, TN 38115
901.246-0159
Not to mention the cha ching factor!
John Harvey
-----Original Message-----
From: profox-bounces@leafe.com [mailto:profox-bounces@leafe.com] On Behalf
Of Stephen the Cook
Sent: Wednesday, March 01, 2006 9:18 PM
To: 'ProFox Email List'
Subject: RE: Business Reasons to rewrite, was: web app
Ted Roche <> wrote this on Wednesday, March 01, 2006 8:12 AM:
> 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.
True.
Stephen Russell
S.R. & Associates
Memphis, TN 38115
901.246-0159
http://spaces.msn.com/members/srussell/
[excessive quoting removed by server]
Ted,
Your well presented post has me thinking the following:
VFP is a great tool kit to develop a variety of small but strategic
applications. I believe the key to being successful with it is to not
bite off more than the product can comfortably chew, and to have
prospective customers (a) perform acceptance testing before buying into
the product, and (b) not making promises that the product can sustain
any/all changes to the customer's environment.
I left the highly stable IBM world after many years for one reason and
one reason only: PC's and MS made it possible to get into the software
business without an up-front million dollar investment. I spent hundreds
to get in - and a million since - but at least the (illusion of?) the
barrier-to-entry was crossed.
What I think gives us different views on the VFP/software world on our
table is that I'm focusing exclusively on a particular application that
I'm telling prospective customers will work in certain environments, and
you're solving very difficult after-the-fact customer problems. We both
have tough roads to how, but I think your lot is another level more
difficult than mine, owing to what MS has done to the PC world.
I could ramble on, but I'll jump to the bottom line: I think folks like
yourself would be much better served by going over to the very complex
but highly stable IBM world then staying with MS or putting together
pieces of different technologies. Linux, I think, is the portal.
Bill
> >
> > 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.
Author: Stephen the Cook
Posted: 2006-03-02 07:51:12 Link
john harvey <> wrote this on Wednesday, March 01, 2006 9:43 PM:
> Not to mention the cha ching factor!
People want to buy new things. Just ask Detroit.
Stephen Russell
S.R. & Associates
Memphis, TN 38115
901.246-0159