I have to say I find your comparison between bridge engineers and software
engineers rather troubling.
In response to your question:
'Would you accept "it was too hard to do a stress analysis" from the
engineer designing a bridge?'
I think, regrettably, we probably would do these days.
Remember that little incident in 2000 when the London millennium bridge was
closed immediately after opening due to excessive wobbling when people
walked across it? I can't guarantee that my recollection is accurate, but
I'm sure they were trying to put this down to that software classic, a
'Design feature'.
Seems that far from Software Engineers taking the bridge engineers
approach, we may be seeing the exact reverse happening. :-)
--
Graham Coles.
Brian Utterback
<Brian.Utterback@ To: George Capehart
<[EMAIL PROTECTED]>
Sun.COM> cc: [EMAIL PROTECTED]
Sent by: Subject: Re: [SC-L] How do we
improve s/w developer awareness? [Virus Checked]
[EMAIL PROTECTED]
coding.org
02/12/2004 13:25
George Capehart wrote:
> Yes, assuming management cares . . . and that's *my* broken record . . .
> :)
>
> If the tone of my comments was a bit harsh, it is most emphatically not
> intended to be directed at your thoughts. It is only because of my
> intense frustration with the situation. When "Management" wants
> software systems to be secure, they will be. Not perfectly so, but
> within published limits. "Management" will see to it that the
> appropriate policies and processes are in place to assure it.
> "Management" will see to it that delivering a product that passes the
> certification process is more important than delivering a product by a
> certain date. "Management" will require that a security architecture
> be in place before the design process starts, etc., etc., etc. The
> board will hold "Management" accountable for the risk that the use of
> the system entails. When that happens, "Management" will come to
> realize that security is *their* problem, *not* InfoSec's problem.
> /Until/ that happens, changing frameworks, development tools,
> methodologies or whatever will not solve the problem. "The Problem"
> just isn't in IT.
>
> As Dennis Miller says: "But that's just my opinion. I could be wrong."
Which brings up the next broken record. Management will not care until
it affects the bottom line not to care. As long as it costs money to
care (missed deadlines, more tools and training, etc.) and it doesn't
cost anything not to care, then they *shouldn't* care. Either the
consumers have to care so that security problems cost sales, or
the liability laws need to change so that security problems result in
financial penalties. Consumers in general are too diverse a group to
really change what they want. It would be very difficult to educate the
entire consumer base to the collateral costs of poor security in
products and to set valid expectations about what is and is not
possible. The "all software has bugs" mantra is now very ingrained.
Changing liability laws on the other hand is a simple solution. This
will force managers to do the proper due diligence just to CYA.
Sure, there will be increased litigation costs, but a couple high
profile cases and the whole process of development will change.
And I don't buy the "programming is too hard, there will always be bugs"
argument. Maybe there will always be bugs, but I don't think we have
reached the point where we can really make a call about how hard it
really is. We call programmers "engineers", but very, very few software
"engineers" deserve the title. Would you accept "it was too hard to
do a stress analysis" from the engineer designing a bridge?
--
blu
It is bafflingly paradoxical that the United States is by far the
world's leading scientific nation while simultaneously housing the most
scientifically illiterate populace outside the Third World.
- Richard Dawkins
--------------------------------------------------------------------------------
Brian Utterback - OP/N1 Revenue Product Engineering, Sun Microsystems
Ph/VM: 877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
