OT - Rant on State of S/w Engr (was Re: Buffer Overruns)

[Lim Wei Siong Vincent <wslim () crtc corp mot com>]

After reading Joseph rant, I can't help but want to put in my two bits too.

Joseph is approaching the problem from one angle, I am travelling towards it
from a different destination.

I think the deplorable situation that we are in today with regards to software
engineering and quality is because of the business environment we are in.
There is no incentive to produce software of good quality when you can get away
with "bugs free" (old joke) software.  Time-to-market, cost and human resource
are irrelevant once the basic problem of wanting to produce software with
little bugs is solved.

Let me use an analogy to illustrate the problem.
You have inherit a nice little piece of land and you want to build a house on
it.  So you approach an architecture firm to get the work done.  The architect
promise you heaven and earth and even allow to make changes to the design of
the house in the midst of construction without charging you extra for it.

On the first day you move, the house collapse on you.  You sue the company and
win the lawsuit with a big little pile of money.

Can you do the same thing in the software industry?  No.......  the current set
of laws does not protect you as a consumer of software.  Of course, everyone
expects bugs, of course everyone wants the latest and greatest features, of
course, everyone wants it NOW!  This has been brainwash into us.  Therefore the
courts does not expect the software industry to produce software with no defect
and offer them the protection of having no consumer protection laws.

Well... I don't expect software with defects and I intend that laws should be
in place to protect me as a consumer.  My belief is that once such laws are in
place, the software industry will have a shakedown.  Companies will be sued
left and right that they will concentrate on producing defectless software
instead of promising you newer features in ever shorter time.  Discipline will
enter the industry and eliminate those that make empty promise.  Of course, for
the short term, innovation will slow as everyone concentrates on producing good
software.  However, innovation will enter the market once their houses are in
order.  Look at the architectural and construction industry, can you claim that
they are not innovative?  But they don't build house that falls down on you.

Well, thanks for the time to listen to this rant.


Joseph S D Yao wrote:

> On Sat, Dec 18, 1999 at 05:45:13PM -0500, Vin McLellan wrote:
> >         It there something in the emergence of a popular Internet, or some
> > other timely aspect in the industry's evolution, that has brought to light
> > the vulnerabilities associated with buffer overruns in recent years?
> >
> >         Maybe some shift in program design or programming engineering
> > practice?  What left so many of these vulnerabilities unexposed and their
> > risks unappreciated for so many years?
> >
> >         Sometimes even in <ahem> widely distributed source code.
> >
> >         _Vin
>
> Vin, pardon me while I rant a bit.
>
> What "recent years"???  This problem, this "vulnerability", has been
> known since the days of FORTRAN.  All beginning programming students
> have been warned about putting something too big into an array that was
> not sized to handle it!  But still, it's been done since arrays were
> created.
>
> Many programmers these days are self-taught.  This is great!  But I
> could wish that they hadn't been hired before they had been taught
> something about software engineering methodologies.  True software
> engineers, or even programmers who use some software engineering
> methodologies, are extremely rare!  And I'm not even talking about
> choosing one of the churches of the holy Methodologies, capital-M, and
> sticking to them as if they were in fact a religion.  I'm talking about
> simple, trivial, easy-but-boring engineering skills, like checking your
> input for validity, checking in each function/subroutine/method, and
> checking your output.
>
> Why has it been seen a lot lately?  I'd guess two reasons.  One is, it's
> a popular "fad".  The guys who get their kicks out of such things have
> suddenly come to the realization that there are such things, and are
> getting their jollies pointing them out wherever possible.  And why is
> this so possible?  That's the second thing.  As you mention, now there
> IS the Web on top of the Internet, that makes so much accessible to so
> many.  I was very glad when the first ISPs made the Internet available
> to me at home.  I was less glad when the next wave arrived ...  but
> that's me being provincial.  Web apps are rushed to market on "Internet
> time".  Applications are not checked for any degree of safeness, if
> they ever were.  Many are written by or for that pre-Internet company
> that thought putting kernel networking code into their word processor,
> so that it wouldn't be bound by having to go through the kernel's
> network security code, was such a hot idea.  ;-\
>
> So.  The problems were always there.  They are not checked for,
> especially when people want apps out yesterday.  Novices are writing
> critical sections of code.  [Novices may have 40 years in the business,
> OBTW; but if they haven't learned anything in 40 years, they're
> novices.]  And it's all out there for everyone to see on the Web.
>
> The Open Source model, if I may be so heretical, has helped some but
> nowhere near enough.  If you believe, with Ted Sturgeon, that 90% of
> everything written is c***, then at least 90% of everyone out there is a
> c***-writer.  No, that wasn't "code".  I won't do the statistics to bear
> this out, but my gut feel is that if you have 3 or 4 people review each
> piece of code THOROUGHLY, then 65+% of the code will still not be
> reviewed by one of the 10%.  And I feel that I am being generous in my
> assumptions.  And it totally does not help with proprietary
> applications.
>
> In my younger days, when people were getting excited about software
> engineering and data-oriented applications, it was felt that if you had
> a number of bright SE's doing code walkthroughs and other such stuff,
> you could eliminate a lot of the common problems.  Nice model.  Most
> shops don't consist of a number of bright SE's.  Those that do, the
> time-to-market overrules.
>
> It's always been there.  Surely somewhere the RISKS listings are
> archived.  It's just that all the dreamed-of advancements in "computer
> science" and "software engineering" never came to pass; and some that
> did have fallen like the seed that was trampled in the field.
>
> OK, I sound pessimistic.  I am somewhat aware of the human condition,
> and I don't expect this condition to be eliminated in my lifetime.
> There are some tools that help people write code without these flaws,
> but some of them introduce other flaws, and most are not as general-
> purpose as we who hack at lower levels would like.  It takes discipline
> to "do it right."  People would rather do an easy hack than a
> disciplined, engineered one.  And public discussion of this does not
> seem to have reached everyone on the planet who codes, just yet.

Whatever opinions that has been expressed in this mail or anywhere else does
nothing to do with the organisation orginating and supplying the mail carrying
capacity.
--
Lim Wei Siong Vincent
Software Resource Engineer

Singapore Software Center - Global Software Division

----- BEGIN GEEK CODE BLOCK -----
Version: 3.1
GE/CS d- s: a- c++ US P++ L>L++ !E W++ N+
O?>O K- W o- M-- V PS+ PE Y+ PGP- t 5 x- R !tv b+++ DI++++ D---
G e+++ h--- r+++ y+++
----- END GEEK CODE BLOCK -----