> From: jkrueger@andrewscg.com
>
> One last public comment, and then we should probably take this discussion
> private...  You and I both know that any conversion tool that
> promises 100%
> success is probably exaggerating its claims; while good software
> developers
> continue to work towards a six sigma level of quality, there is too much
> undocumented/unanticipated behavior in software for anything to
> work at a 100%
> level.

Actually, my technique lends itself rather nicely to a 100% conversion rate,
because the converted programs still function in their original green-screen
mode.  Note that there are two distinct pieces here: conversion of the
existing program and implementation of the user interface.  As you point
out, the user interface is a separate issue, and can be a great deal more
difficult than the actual conversion.  At this point, I'd guess my UI
implementation success rate to be in the high 90's for the green screen
emulation mode, primarily tempered by a set of unsupported keywords.  The
rate will go up as we build in more keyword support, although some areas
will probably never be supported, such as the GUI keywords.

Also, my generated pages are usually under 2KB.  I'm not sure how well
Innovator works, but the Jacada for HTML pages I've seen are regularly 50KB
and more.  In 2000 at least, they also required considerable hand-tweaking.


> The Jacada people promise a 95% success rate, because
> they explicitly
> want their users to go through a full testing cycle, just in case.

Um, this sounds (to me!) like political doublespeak.  Tell us what the
expected conversion rate is, and also tell us we should test everything.
Clients can make up their own minds.  But to instead couch terms in order to
manipulate your clients' actions implies a rather low regard of ther
intelligence.  Personally, I think my clients are very savvy folks and can
competently make decisions given the facts, so I tell them the real numbers
and let them decide.  Maybe that's just a difference in how Jacada and I
treat our customers.


> Your claims, on the
> other hand,
> sound too good to be believed, and could encourage people to
> deploy converted
> applications without a full test...  That, in my opinion, is
> dangerous and tends
> to lead to disappointed users...

Your opinion of your assumption as to of how users would react
notwithstanding, part of the PSC400 development cycle is a full assessment
on the client machine with test applications prior to even committing to the
development cycle.  Remember, I developed the Focus/2000 Y2K remediation
software, so I have a fairly strong background in sofware modification
procedures, including the concept of establishing appropriate user
expectations.


> In my experience, (...) the users end up in a severe state of
> disappointment and disenchantment, because even though you
> delivered what they
> asked for, it isn't what they wanted!

That's why we do an assessment before the client commits to the purchase,
and take the time to actually teach them about web application design and
how web applications work, including the difference between the
server/client and client/server paradigms.  In a nutshell, a product like
PSC400 cannot provide a web interface to business logic they don't already
have written into their legacy systems.  That's why I partner with Linoma,
because their Ambassador product picks up where PSC400 (or Envoy, as they
distribute it) leaves off.  With Ambassador, you can write new business
logic as true servers and integrate it into your web application.  Of
course, you can do that with Envoy as well, you just have to write the
program as a traditional green screen application and then convert it with
the single CNVPGM command.  Which way you choose depends on your development
style and the skills of your staff, and will probably progress over time.

Joe Pluta
www.plutabrothers.com



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.