Xref: utzoo comp.sw.components:373 comp.software-eng:2248
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!rit!mjl
From: mjl@cs.rit.edu
Newsgroups: comp.sw.components,comp.software-eng
Subject: Re: Software quality
Message-ID: <1357@cs.rit.edu>
Date: 24 Oct 89 03:22:18 GMT
References: <1989Oct19.042903.7809@ico.isc.com> <6847@hubcap.clemson.edu>
Sender: news@cs.rit.edu
Reply-To: mjl@prague.UUCP (Michael Lutz)
Followup-To: comp.sw.components
Organization: Rochester Institute of Technology, Rochester, NY
Lines: 72

In article <6847@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From rcd@ico.isc.com (Dick Dunn):
>> As for the "management decides, engineers comply" - in some sense that's
>> what happens, but it's an incredibly poor choice of words.  That is,
>> regardless of the actions, an organization which sees its process in those
>> terms is not healthy...it has management problems.
>
>   No, it in fact shows that the organization IS healthy.  Engineers
>   are not, and should not be in the business of trying to be, responsible
>   for setting cost and schedule constraints.  They ARE responsible for
>   providing as much information as possible to management as it weighs
>   technical and economic factors in the process of making the decision.
>
>   If engineers were responsible for setting cost and schedule constraints,
>   they would tend to disregard economic factors and the organization would
>   quickly find itself out of business.  Projects would be technical works
>   of genius, with complete formal specifications for each subprogram or
>   data abstraction, 3-D images illustrating the design, etc., at a cost 
>   which would result in fatal financial illness for the company. 

I can't let this one pass, if for no reason than to defend the honor of
engineers.  I don't think we can (or should) use the Nuremburg defense
"I was only doing what I was told." If engineers realize that
managment's requests/requirements/demands are impossible to achieve,
they have the right -- the obligation -- to object, if for no other
reason than to protect the shareholder's interests against the
unrealizable plans of management!

Like most others who've been in this business for any time, I've seen
examples of what Bill is talking about.  Still, this was usually due
less to engineers violating budget and time constraints than it was a
lack of management direction -- by which I mean setting clear goals for
what was to be done.  People fritter their time away when they don't
have a clear vision of where they're going.  But once goals are
established, the engineers should have significant if not primary
control over how to get there.  Most fiascos I've seen have resulted
from management inability or unwillingness to face facts: what the
project would cost and how long it would take.

I have no problem with management proposing budget and schedule
constraints, but the engineering staff is best qualified to determine
whether there is a feasible solution within these constraints.  And
"feasiblity" in this case includes adequate time to produce a quality
design that has a high probability of successful evolution over the
lifetime of the product.  Bill's snide remarks notwithstanding,
sometimes this will mean creating a formal spec. and a variety of
related models to ensure a well-engineered piece of software.

In my experience, managers consistently underestimate software product
lifetime, possibly because they base their estimates on hardware
development models.  When the hardware subsystems are no longer up to
snuff, they are are often redesigned *from scratch* using the latest
technology.  However, most organizations work under the implicit
assumption that software need *never* be redesigned from scratch --
it can always be modified to meet new requirements.  I have in mind
several projects I've been involved with over the past couple of years,
where the hardware base evolved in stages from first generation mini's
(like PDP8's and Nova 1200's) to 68K's and 80xxx's.  While the current
processor boards and attendant interfaces look nothing like their
ancestors, the current software system architectures still reflect the
original designs (or lack thereof) from the early 70's.

For those interested in the issues surrounding long-term product
evolution, I strongly recommend Belady & Lehman's book "Program
Evolution: Processes of Software Change" (Academic Press, 1985, ISBN
0-12-442441-4).  The typography is awful, and I think the proof reading
phase was skipped, but the ideas and insights are well worth the time
it takes to ferret them out.
Mike Lutz	Rochester Institute of Technology, Rochester NY
UUCP:		{rutgers,cornell}!rochester!ritcv!mjl
CSNET:		mjl%rit@relay.cs.net
INTERNET:	mjl@cs.rit.edu