Genotypes and Phenotypes (Gunnar Peterson)

[cwysopal at Veracode.com (Chris Wysopal)]

This seems to boil down to an economics problem.  Notice how quickly the bean counters showed up after the thread began 
with a discussion of bugs and complexity.  It is just too inexpensive to create new code and there isn't enough 
economic pain when it fails for anything to change for most software.  In certain cases like aircraft where the 
economic pain of failure is high you get DO-178B, Software Considerations in Airborne Systems and Equipment 
Certification.  For that type of software you might see the purchase of highly reliable libraries that have also met 
that certification.

-Chris

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org] On Behalf Of Andreas Saurwein Franci 
Gon?alves
Sent: Wednesday, October 14, 2009 9:49 AM
To: Secure Coding List
Subject: Re: [SC-L] Genotypes and Phenotypes (Gunnar Peterson)

2009/10/14 SC-L Reader Dave Aronson <secureCoding2dave at davearonson.com<mailto:secureCoding2dave at davearonson.com>>
Andreas Saurwein Franci Gon?alves <saurwein at gmail.com<mailto:saurwein at gmail.com>> wrote
(rearranged into  correct order):

> 2009/10/13 Bobby Miller <b.g.miller at gmail.com<mailto:b.g.miller at gmail.com>>
> > The obvious difference is "parts".  In manufacturing, things are assembled
> > from well-known, well-specified, tested parts.  Hmmm....

> Thats the idea of libraries. Well known, well specified, well tested parts.
> Well, whatever.
Ideally, yes.  However, programmers love to reinvent the wheel.  It's
MUCH easier, both to do and to get away with, in software than in
hardware... and often necessary.

Need a bolt of at least a given length and strength, less than a given
diameter?  There are standard thread sizes, and people make bolts of
most common threadings and lengths, for purchase at reasonable prices,
at places easily found, and you can be fairly certain that any given
one of them will do the job quite well.

Need a function for your program?  If it's as common as a bolt, it's
probably already built into the very language.  If it's nearly as
common, maybe there's a fairly standard library for it... and if
you're very lucky, it's not too buggy or brittle.  Otherwise, it's
probably going to be much cheaper (which is all your management
probably cares about) to just code the damn thing yourself, than to
research who makes such a thing, which ones there are, who says which
one is how reliable, which ones have licensing terms your company
finds palatable, and justifying your choice to management.  Lord help
you if it requires money, because then you have to justify it to a
higher degree, get the beancounters involved, budgetary authority from
possibly multiple layers of manglement, and spend the rest of your
days filling out purchase orders.

If you do wind up coding it yourself, is the company then going to
make that piece of functionality available to the world separately,
whether for profit or open source?  N times out of N+1, for very large
values of N, no way!

Will they at least make it available *internally*, so that *they*
don't have to reinvent the wheel *next* time?  Again, N times out of
N+1, for almost as large values of N, no.

-Dave

Exactly thats the point. Going a bit further, for every piece of  hardware engineering, there is almost always a legal, 
worldwide or at least national standard to follow. This is inexistent in software.

As long as anybody with at least one healthy finger is allowed to write and sell software, the current situation will 
not change.

Make software development an engineering discipline with all the rights and obligations of other engineering sciences.

No more coding without a license. Point. This would change the landscape of bits and bytes in a dramatic way. But it 
requires the support of the governments worldwide.

My 2 cents (me too would have to get back to college and study some more, although having 25+ years of software 
development experience)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20091015/f1c377ff/attachment-0001.htm>