Path: utzoo!mnetor!uunet!husc6!bunny!jwg1
From: jwg1@bunny.UUCP (James W. Gish)
Newsgroups: comp.software-eng
Subject: Re: A Cynic's Guide, part 1
Message-ID: <5753@bunny.UUCP>
Date: 11 Mar 88 22:04:59 GMT
References: <2541@Shasta.STANFORD.EDU> <3584@bloom-beacon.MIT.EDU> <7982@tut.cis.ohio-state.edu>
Reply-To: jwg1@bunny.UUCP (James W. Gish)
Distribution: na
Organization: GTE Laboratories, Inc.
Lines: 45

In article <7982@tut.cis.ohio-state.edu> karl@tut.cis.ohio-state.edu (Karl Kleinpaste) writes:
>tada@athena.mit.edu writes:

>This is related to the abysmal management styles that seem to go with
>software management.  "If it's not perfect, that's OK, we'll fix it in
>release 2.  Just get us on the market *first*."  The investment to
>repair faulty hardware already in the field is positively monstrous;
>the investment to repair faulty software in the field is (perceived to
>be) small.
>...

I agree, this is one of the biggest parts of the problem.  As part of
the abysmal management that seems to go along with software
development is a real reluctance on the part of many managers to buy
appropriate tools to help do the job.  I attribute this to the
perception that software tools are not "tangible" in the eyes of many
beancounter-managers and thus find their acquistion difficult to
justify - unlike the purchase of hardware tools that they can touch
and feel and stub their toes on.

Another important difference between quality/productivity in hardware
vs. software development is one of maturity of the fields.  Hardware
has had a lot more time to develop disciplined approaches than the
software field has.

Also consider that the notion of "pluggable modules" and well defined
interfaces is taken for granted when building hardware (although I've
seen some pretty messy boards with lots of patches).  Standard
software interfaces/components are still along way off.  This is due
to many factors that I'm sure most of us can relate to (inertia of
obsolete languages, programmer eccentricity, programmer fear of <fill
in your favorite fear>).  Many programmers do not trust existing code,
often for good reason, so there is usually a direct impact of the "not
invented here" syndrome on productivity and quality.  A good deal of
the problems with software reuse are
cultural/psychological/organizational, but we are far from solving the
technical problems of software reuse.




-- 
Jim Gish
GTE Laboratories, Inc., Waltham, MA
CSNET: jwg1@gte-labs    UUCP:  ..!harvard!bunny!jwg1