Hi Dave --

> Running: Three years ago, we could run from back code. 
> Today, not as easy. You learn to live w/in the confines 
> of the current stuff and survive. If you get paid for 
> your time, you are ok. If you get accused of causing 
> the problem, and it is not your problem, you are now 
> not okay. Therein lies the hitch.

I hope you don't mind me saying so, but this sounds like a
client-business relationship problem rather than a tech or budget
problem.

At the risk of going out on a limb here, it sounds like you (or your
team) wrote some software a few years ago which has not aged as well as
the client expected.  That's life!  Software is made by humans, and
humans are fallible -- therefore software if fallible.

Not all clients are receptive to this idea.  Sometimes, they get the
notion that they are paying for a "perfect" piece of work, and it is
often difficult to correct this idea.  In fact, they're paying for "the
best possible work, given the skill-level of the workers at the time,
given the state of the art at the time."  That means bugs, security
holes, and performance problems.

If the client is completely happy with the work, then you're correct:
Don't change anything.  Don't add mod_perl, and don't fix the code.  Put
more succinctly, "if it ain't broke, don't fix it."

If, OTOH, performance has become an issue (as the discussion of adding
mod_perl may suggest), I suggest another tactic:  Be completely honest
with the client.  Tell them the code has bugs which have to be fixed
before any performance improvements can be made.  Come up with an
incremental plan to re-write the application, one part at a time, to
smooth out the budget issues.  

You can implement this at the server level by configuring mod_perl to
treat the older scripts as regular "mod_cgi" ("*.cgi") applications, but
run re-written scripts via Apache::Registry ("*.pl"):

    AddHandler cgi-script .cgi
    <FilesMatch "^.*\.pl$">
        SetHandler perl-script
        PerlHandler Apache::Registry
    </FilesMatch>

Perhaps, as they see the performance kick of mod_perl, the client will
be more motivated to do a full re-write.

TTYL,

-Jesse-


--

  Jesse Erlbaum
  The Erlbaum Group
  [EMAIL PROTECTED]
  Phone: 212-684-6161
  Fax: 212-684-6226




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Html-template-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/html-template-users

Reply via email to