Xref: utzoo comp.sw.components:308 comp.software-eng:2103
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!mrspoc!itkin
From: itkin@mrspoc.Transact.COM (Steven M. List)
Newsgroups: comp.sw.components,comp.software-eng
Subject: Re: Schedule and budget are secondary
Message-ID: <1989Oct7.170247.17849@mrspoc.Transact.COM>
Date: 7 Oct 89 17:02:47 GMT
References: <6630@hubcap.clemson.edu> <16168@vail.ICO.ISC.COM>
Reply-To: itkin@guinan.Transact.COM (Steven List)
Organization: Transact Software, Inc.
Lines: 71

rcd@ico.ISC.COM (Dick Dunn) writes:

> ... stuff deleted ...

>In any event, a single "schedule end date" or "cost" for a software project
>is carelessly simplistic; it's as bad as rating processor performance on a
>single number.  You need to associate confidence levels with the values.

>But overall, Wolfe has it backward.  You need to produce quality software
>that does what it's supposed to do.  Then you need to do it predictably.
>But if the software doesn't work, it doesn't matter how quickly or cheaply
>it was done.
>-- 
In reading what Dick said, I can only believe that he's never worked on
a project for which someone ELSE was paying.  Or a project for which the
market window is critical to the continued survival of the company or the
project or the product.  He implies (probably unintentionally) that Mr.
Wolf's approach is unrealistic and financially motivated.  He says that
his statements will come as a surprise to the Academicians.

Dick's statements strike me as somewhat ivory tower.  While those of us
who consider ourselves professionals in the field of "software engineering"
presumably ALWAYS strive for quality products, we can't just turn off our
systems and refuse if someone comes along and says "we have a deadline".
Rather, we have to make every effort to compromise and push and squeeze
and produce the required product in the required timeframe and within
the specified budget.  This is REALITY.

Now, I don't want Dick to misunderstand.  I laud his goals.  I too
believe that our first goal SHOULD be quality software.  Define quality.
Unfortunately, too often, that translates to "as much functionality as
can be gotten in that works reliably as we can fit within our
constraints".  Happily and sadly, we live in a commercial environment.
As such, we are controlled, largely, by the need to earn dollars so we
can continue to do what we enjoy doing.  Having become a principal in a
business within the last couple of years, I've had to learn this lesson
even more painfully than before.

No doubt, there will always be those who will take one side or the
other.  "Quality MUST come first, even at the risk of lost opportunity
or lost business."  "Meeting our deadlines and our budgets is paramount.
If the product isn't up to standards, well, we'll adjust later or change
our marketing."

The truth is that living in the real world ALWAYS requires compromise.
From what time you get up in the morning to what you eat for lunch to
whether or not you include a feature in the software you are developing.
To survive, you must adapt.  Adaptation FREQUENTLY requires compromise.
So, I guess, I believe that you have to fit all things together.  The
question I must always ask myself, when we start a project or task, is

    "How much can I get in that meets MY/OUR/OUR CUSTOMER'S standards
    of quality within the time and budget constraints set forth?  Can
    we modify the constraints?  Are we willing to adjust our standards?"

Dick's statement that producing a schedule that meets a lower confidence
factor would permit a favorable decision is frightening to me.  This
implies that it's okay to plan based on 80% or 70% or lower confidence.
This implies that he is willing to proceed based on the assumption that
HE CANNOT SUCCEED in meeting time or budget constraints.  Dick - who's
funding you?  What happens when the date for which you had 70%
confidence comes and goes?  Who eats it?  I would rather produce a
realistic project plan up front, including specifying the compromises,
than to produce a falsely optimistic plan with a qualifier ("this is
only 70% certain") and have to scramble to adjust near the end.
-- 
 +----------------------------------------------------------------------------+
 :                Steven List @ Transact Software, Inc. :^>~                  :
 :           Chairman, Unify User Group of Northern California                :
 :     {apple,coherent,limbo,mips,pyramid,ubvax}!itkin@guinan.Transact.COM    :