Did you ever write a program? Did it work the first time, doing exactly what it was supposed/specified to do?
Did you ever figure that was an adequate excuse?
Of course not.
Not in what you say isn't the truth, because any software that hasn't been shaken down is usually pretty bad, but using the "first time" as an actual reason for insecure software? Completely unacceptable. If you worked for me with that attitude, you might end up in the mail department where you could have an easier job.
You obviously both misparsed my statement and aren't aware
of how *I* do software development.
It includes beating the HELL out of any piece of software before
releasing it (with a full coverage test suite built into the make
mechanism in a way that causes the build to fail if a unit test
I've developed a methodology that lets me deliver such a fully
debugged software components, with test suite blazingly fast,
as well. It takes me about three times as long as it takes a
more typical programmers to get a new component of similar
size and complexity to successfully compile and link (but not
run correctly) after a moderate feature change.
And I'm thus familiar with some of the pathologies of
people who administer programmers with insufficient
insight into what they're doing and their modes of talking
about it. Because I'm so fast I don't generally report
progress until a component is DONE. Result: Some
administrators have compared my delivery of a complete,
polished, from-scratch, component to one debug iteration
of other team members. This lead to actual publication of
a statement to this effect: "[Ungrounded Lightning Rod]
takes three times as long as anyone else, but his stuff
usually works the first time."
I've been referred to as "a god" in hushed tones (over a
nearly non-existent bug rate in a ten thousand line application),
and had a colleague comment that I was the only person he'd
rust to program an artificial heart for him.
So I'm quite aware of how to make software solid.
My point was not making excuses for poor programmers.
My point was that commercial software operations usually
have management pathologies that lead to measuring
function and not measuring (or rewarding) security.
There's a lot of WORK involved in making software secure
and doing it is usually penalized rather than rewarded. So you
have to expect commercial software to USUALLY be riddled
with security bugs.
(Which is why I migrated to hardware design about 15 years ago.
The non-recurring costs of a bug-fix respin as SO high that
administrators often appreciate and reward solid design and