Re: Lame studies that people quote as fact that have no basis in reality and still don't prove anything even if they did

["Matt Hargett" <matt () use net>]

> This is crap. If you spend your whole life looking for security bugs in
> your product, then you find them. Continuously. You'll end up finding at
> least 100 times more than will ever come out in public. So you really
> save a lot of money by doing everything in the QA phase, where it belongs.

You had to go and mention QA, didn't you? Is this an attempt to bait me? ;>

I don't know where this idea that it's QA's job to magically find all the
bugs started. Himuckamucks of previous decades (Brooks, Yourdon, etc)
certainly didn't further this conception in their writings. I can tell you,
having done a bit of QA myself, that saving things up for QA is not an
optimal way to conduct a software project. Especially when you have
little/no format QA going on.

Like I said in my talk, it only takes a vvvvery small amount of up front
work to dramatically optimize the use of one's time. Most coders I know like
to spend their time writing new code or innovating/improving old code, so it
seems they would be very interested in making sure they could do that as
much as possible. Unfortnately, most coders (not the same as a "software
engineer" or "programmer") do not have that foresight. Fortunately, some of
them do eventually graduate upwards after wasting copious amounts of their
time, stressing themselves into unhealth, and looking bad for consistently
delivering shit code that is often late (by their own defined schedule!) as
well.

I call these people "cowboy coders", and they are pretty easy to detect.
They either don't use source control at all, or use it in a way that reduces
its' usefulness to large degrees. For instance, mass check-ins of many (or
all) files in the project with no checkin comment. Even a fuxing trail of
bread crumbs would be better than nothing to people have to maintain the
code. They also will constantly under-estimate how long it takes them to get
something done because they are constantly playing the prick-waving game
even to the detriment of the product or business they have put so much
effort into. Another giveaway are people who "can't" work without pointers
and/or loose typing. They also seem to be very afraid of people
understanding their code for fear that they might be replaced.

 Once place I worked a coder refused to let us back up the source only on
his machine, then when we rooted his box and set up an NFS mount so we could
do so. When he found out we did this (we had burned a CD and sent it to the
east coast where "management" was), he was very calm. He then calmly came in
to the office late one night and rm'd the machine we were backing up to.
This isn't even the best of these stories, but is a good example. One could
say that this extreme behaviour doesn't generally happen. One would be
right, but the underlying attitude is exactly the same. An organization
without the aid of a monopoly or act of g0d is at a significant disadvantage
with people like these in its' midst.

Anyways. Only when proper requirements, A&D, unit testing, and automation
are done up front will QA not have to waste their time compensating for
those deficiencies. Then they can actually do real testing! Fathom that! To
assume QA will make up for the slack at every one of these points is utterly
retarded at best, and totally negligent at worst.

Not that I have a strong opinion on this subject, or anything :)

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave