Re: Application Insecurity --- Who is at Fault?

[Dave Paris <dparis () w3works com>]

Michael Silk wrote:
[...]

Consider the bridge example brought up earlier. If your bridge builder
finished the job but said: "ohh, the bridge isn't secure though. If
someone tries to push it at a certain angle, it will fall". You would
be panic stricken. Fear would overcome you, and you might either run
for the hills, or attempt to strangle the builder... either way, you
have a right to be incredibly upset by the lack of 'security' in your
bridge. You WONT (as is the case now) sit back and go: "Oh well, fair
enough. I didn't ask you to implement that, I just said 'build a
bridge'. Next time i'll ask. Or make sure the public specifically
requests resistence to that angle of pushing".

Hopefully my point is obvious...

[...]

Actually, it's obvious - but I still can't agree with it.

Using the bridge example, it's fairly trivial for the ironworker to 
realize there should be guesset plate where one wasn't called for.  It's 
a small piece, fairly quickly and easily fabricated and attached - so 
the ironworker puts it in.  No, it wasn't part of the specification - 
but the ironworker has built enough bridges and can explain away the 
extra half-day and slight cost it took to add the appropriate guessets.


On the other hand, the ironworker has worked on enough bridges to 
realize that <insert scenrio of inappropriate design here> will lead to 
a functional, but flawed bridge.  It won't fall down, but it won't be as 
robust as a bridge should be.  The bridge was specified to support 10 
tons.  Five years from now, the road traffic will have 15 ton trucks and 
the bridge may fail.


What you're proposing is that the ironworker should reengineer the 
bridge in-situ (as if he even has the authority!), causing weeks of 
delay, cost overruns, and possibly lead to his employer never getting a 
bridge contract again.


Somehow, that just doesn't hold water.
Kind Regards,
-dsp