Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!mips!prls!pyramid!athertn!hemlock!mcgregor
From: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Newsgroups: comp.software-eng
Subject: Re: recap so far
Message-ID: <27199@athertn.Atherton.COM>
Date: 17 Jul 90 00:31:42 GMT
References: <1990Jul10.134226.22459@iti.org> <268462df> <39400111@m.cs.uiuc.edu> <31558@cup.portal.com>
Sender: news@athertn.Atherton.COM
Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Organization: Atherton Technology -- Sunnyvale, CA
Lines: 88

In article <1990Jul10.134226.22459@iti.org>, john@iti.org (John Sauter) writes:


> >Engineering deadlines are by default flexible. You can't market a TV
> >that does not work, right? Therefore the deadline gets moved whether anyone
> >likes it or not. And I see evidence that those engineers are not
pressured to the 
> >same degree as programmers. Management knows that pressure = errors = 
> >delayed completion = increased costs. (But then you have to weed out loafers
> >who take advantage of a non-production environment to not produce.)
> >==========
> I don't think that hardware engineering works this way.  Talking to
> my HW engineering friends I find that they are faced with deadlines
> and schedules just like I am.  Do you think GM is going to delay a
> new product introduction 6 months because some engineer ran into a
> design problem?  If there is a problem anywhere, they throw people at
> it and resources until it is solved.  If that fails they always
> have something to fall back on: use last year's design.  In any case
> there is sufficient differences between the realm of HW engineering
> and SW engineering that has been discussed at length here.  I don't
> believe we will find a solution to our problems from the HW
> engineers (except in understanding the need for rigor, structure
> and discipline as we have better tools and techniques to work with).

I think that John is correct.  In all disciplines management views
their job as making tradeoffs between time, quality and functionality.
This is as true in hardware as software.  These three define an
triangle whose area is determined by resources applied, any two of the
three can be changed and the area still kept with constant resources.
Management can manage the slow progression to a particular configuration
by the application of resources and the emphasis of particular goals.
Because the area also represents VALUE to the customer there is always
pressure to get as large an area as possible with the smallest amount
of resources.  This ratio represents EFFICIENCY of production.

In general, management of software does want solid schedules.  I find
that  engineers  often internalize their own goals and are less 
flexible in changing functionality and quality than management might be.
I believe that this is a social aspect.  Engineers don't like to shave
functionality because it is the thing that they want to do--that's why
they entered the trade.  Engineers don't like to shave  quality because
of self-integrity, they want to feel they did a good job by their own
internal measures.  Time frames are typically less important to software
engineers, so they would feel better sliding the schedule and holding the
other aspects constant.  Since managers often get measured on what ships
and not how much work was done, their is a social opposition here. I
believe   these are the reasons why we see tension between software
developers and
their managers on "unreasonable schedules".  Note, these are definately
observations about large groups of people, and may not be true of all
people who are developers or managers.  I just note a propensity in terms
of differing personal and institution reward structures that lead to
potential conflict over this issue.
engineer

> I agree.  There is a marketing problem here.  Just to market a single
> version of a reasonably complete set of objects for a single programming
> domain (say GUI's or DBMS) requires an immense number of objects.
> Just browse through the Smalltalk classes for an example.  You could
> spend several man-months (even a man-year) just trying to understand
> all that is in there.  To suggest that we could have several versions
> of each of those classes/objects begins to exceed any human capability 
> to successfully market and use that number of objects.  The best
> approach is stil the availability of source code for modification, but
> alas we run into a greater business problem with that approach.

This may be a false problem.  There are already many more hardware devices
in catalogs than most people can learn about and remember.  People don't.
They only remember a subset that proved useful in the past, and maybe
ask others around them.  They only bother to keep up with a few new
products each month and maybe incorporate them.  Products that aren't
widely used often go out of  production.  And people often don't develop
the "optimal" board because the possible permutation set is huge.  Instead,
they build the best "satisfactory" board that they can given their current
knowledge set.   Some companies, and some individuals then get an advantage
because their designers know something about an important class of tools
that competitors don't.  They make better designs and this makes them
more valuable (more  profitable).  But they  never really reach optimum
and their are always opportunities for further improvement that competitors
can exploit.  

Even in software, it is typical in rich languages such as PL/I, or editors
such as EMACS, that people only master a sufficient subset of the 
possible commands in order to solve their problems.  People with a richer
subset, or a subset in the right area can have an advantage over others.

Scott McGregor
mcgregor@atherton.com