Posted by rlee0001 on 02/13/06 07:06

Roman,

I don't think its nessisarily a sales tactic. Generally I think a PHP
programmer should analyse the code and if it has any major problems
make the client aware of them; leaving the decision up to the client.
So the fact that the developer offered to do a rewrite isn't
nessisarily a bad thing as long as he can give a clear explaination as
to why this is nessisary.

I strongly beleave that most programmers that shy away from working
with existing code do so because they are not talented or experienced
enough to understand how it works. For example I have been coding in C
for a number of years but I can't even begin to understand how a
program like Linux or Firefox works. I get lost in the code too easily
and therefore would certainly opt not to attempt to modify that code in
any way. With PHP on the other hand, I have much more experience and I
have never seen a program that I could not fully understand and modify
if nessisary.

For me I am just not comfortable signing off on a paid product that I
know isn't coded properly. So when I see existing code that is poorly
written I am very upfront with the client about that fact and try to
explain that using the existing code may have specific disadvantages.
But its ultimatly up to the client whether to pay for any extra time it
takes to rewrite or repair the application, or to use the existing
faulty code.

That said, if I am told to leave the existing faulty code in place I
obviously won't guarantee the product. If the client has problems down
the road and wants me to fix them after the fact, I will charge the
customer again for the additional repairs. Where-as when I write a
product for a customer from scratch (or am allowed to repair an
existing product) I provide more-or-less a lifetime guarantee that the
product will remain functional. Examples of how a program may be
written incorrectly and suddenly need repair:

a) Vulnerabilities to SQL injection attacks or other attacks such as
sendmail injection.
b) Reliance on non-standard server configurations (short tags, register
globals)
c) Lack of error handling when, for example, a database server goes
down.
d) HTML/CSS/JScript that is not cross platform compatible (such as
IE6-only pages).

I could go on but you get the idea. If a program is poorly written and
the client later changes servers, gets customer complaints or is hacked
into I refuse to be held responsible just because I was the last one to
look at the code (unless I was paid to fix the code; in which case I
will take full responsibility and promptly repair the code at no cost).

This is the philosophy you should expect from any developer. He should
tell you if the initial code is faulty and explain those faults in
detail including any costs associated with fixing them. Then he should
leave the decision-making up to you (your the boss).

In case it is a sales tactic: tell the developer the timeframe and
compensation amount and make it very clear that deliverables must be
completed by the deadline. If they think they can code the application
from scratch in that amount of time let them go for it.

As always: require that their code be well written and commented and
require a written guarantee against SQL and sendmail injection
vulnerabilities. Require a demo of the product on a correctly
configured production server. If anything fails require an immediate
fix at no cost. You might also confirm that malformed user input is
being properly validated. If possible, take the database server offline
to check that connection failures are being handled gracefully.

-Robert

[Back to original message]