🚀 go-pugleaf

itkin@mrspoc.Transact.COM (Steven M. List) writes:
>...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...

You are quite wrong on both counts.  I have worked on both for many years;
currently most of my work falls into projects paid for by customers.  I
think it's not that we are in any fundamental disagreement (we'll see) so
much as that we're driving at different points.

> 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".

Understood completely.  I'm NOT trying to put quality at the very top of
the list, to the exclusion of schedule and budget...but I want to get
schedule/budget off the top of the list.

One of the things we have to consider in bidding a software project is that
we want to set a reasonable cost which will allow us to produce a product
of sufficient quality that the customer is not only happy with it in the
short-term (meeting the immediate needs) but in the long term when it comes
time to modify it.

If it's our own product, we don't want to do a quick hack that will save us
10% on the first release and cost us 50% more in the second release when we
have to repair the damage we did by hurrying.  Sometimes, market pressures
are extreme enough that it's the only way to hit close enough to the market
window that there can BE a second release--but we need to avoid that.

>     "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?"

This is a good statement.  The software MUST meet its requirements, but
that's a separate issue.  We MUST schedule enough time and money to do
that.  Then we try to schedule enough to produce a product of sufficient
quality that we won't hate ourselves for it later on.

> 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.

Sure--why not?  Wait, let me qualify that...There are circumstances where
it's OK to work at that confidence level.  Just remember that nothing is
black and white here.  Suppose we're talking about a product aimed at a
particular market window.  What's the accuracy of the end date on the
market window?  Probably 50% at best!  (That is, the window is at least as
likely as not to close AFTER the estimated end date.)  Also, the window
doesn't just slam shut...it means that the longer you delay, the smaller
your market share.  You have to work with the probabilities involved.  If
there's a 70% chance you can make the stated market window, you also need
to know something like what your 90%-confidence completion date is, and
whether that might come in acceptably close to the window that it will
still give you a good product--enough to make some money even if not as
much as you "should" make.

There are literally SCORES of other factors to consider.  The better the
condition of the company, the more of a gamble you can afford to take.  You
may build the company's reputation in a new technology area; you may gain
expertise you need as a side-effect of the project.

You have to look at the type of contract you're going to work with, if
it's contract work.  You can bid base cost plus T&M at a lower confidence
level than fixed-price, which in turn can be lower than fixed-price-with-
penalty-for-late, which is different from fixed-price-with-bonus-for-early,
etc. to endless detail.  Sometimes you don't even bid because the terms
your customer wants don't fit with the amount of risk (which translates
into level of confidence for a plausible schedule) for the project.

> This implies that he is willing to proceed based on the assumption that
> HE CANNOT SUCCEED in meeting time or budget constraints...

No, it implies that I might be willing to proceed even with the knowledge
that the desired (ideal) outcome is less than certain.  But it involves
lots of other considerations, per above, if you're going to go ahead from a
lower confidence value.

>...Dick - who's
> funding you?...

Our customers.

>...What happens when the date for which you had 70%
> confidence comes and goes?  Who eats it?...

If the project is begun at a low confidence level, there will be aspects of
the contract which anticipate that.  If an estimate carries a low confi-
dence, that's taken into account.

>...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.

It depends on what the curve of confidence level vs schedule looks like.
All such curves have a tail asymptotic to 100%.  With some, the shape of
the tail heading out past 75% or so is unpleasantly long...that tells you
that the project is riskier than average, and you have to decide whether
you can live with the risk.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...No DOS.  UNIX.