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

[Blue Boar <BlueBoar () thievco com>]

Chris Eagle wrote:
> The quote is a classic software engineering statistic designed to motivate
> people to do proper requirements analysis and design.  They are not talking
> about cost in incident response terms or damage caused by exploited
> vulnerabilities, they are talking strictly about the cost of modifying the
> software after it has been released vice doing it right in the first place.

Years and years ago, I used to do QA for game companies.  They generally 
did a pretty good job of making sure that games worked when shipped. 
I'm of the opinion that a lot of this was because back then a game was 
shipped on a floppy or two. If you ever had to ship out a replacement 
floppy to all of your users in the future, then your profit was gone.

Now, people expect to have to download multiple rounds of 100MB patches, 
even for games.  I will, of course, grant that current games are much 
larger and more complex, but it's hard to come up with a ratio of 
size/number of patches when I keep dividing by zero.

> IE is a good example.  It is so poorly designed and so interwoven with the
> O/S, that small changes today have a huge impact and require significant
> resources to make sure they didn't break a ton of other stuff when they made
> the fix.  If it was well designed in the first place the theory goes, they
> would have fewer bugs today (less cost) and the ones they do have today
> would be easy to fix (less cost).  But of course I am not a big fan of
> software engineers because none of the ones I know can code worth a damn.

And who does it "cost", exactly?  Distribution costs are largely gone 
(or insignificant), the PR hit is negligible, and the support calls are 
paid for by the customers.  I imagine that it's relatively easy on the 
actual developers to fix the bug, they've been handed a pointer of sorts 
to the broken piece of code.  The only ones I see working hard are 
QA/release management.  They're the ones who have to make sure that 
regression testing is done, that the fix actually works (and check that 
there are no obvious bugs still there related to the original one) and 
make sure the patch executable is robust.

Not that QA is free, but it seems like an easy place to throw money if 
you've got lots to spare.

I'm not convinced that any older studies regarding costs to fix at 
different points in the lifecycle are valid for the current MO of big 
software companies.

In other words, I thinks the costs of fixing things after the fact has 
gotten so much cheaper that it makes financial sense to go ahead and 
allow for that.

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