🚀 go-pugleaf

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,
2847 ) writes, among other things, that:
>    ...But engineers don't play; this is left 
>    for hackers.  We're here to engineer products on time, under budget,
>    and with as much quality as we can get within those two constraints.

Actually, engineers *do* play; the ones who don't seem to be playing are
playing at being engineers.  But that's another posting.  Here, I want to
assert that the "on time, under budget" phrase is a red herring.  (BTW, why
not "ahead of time, on budget" or even getting both right and being "on
time, on budget"?  But that's another digression...)  It's particularly
sad to see "quality" a poor third to the other two.

You can make any feasible software project come in on time by setting a
long enough schedule, and of course you can bring it in under budget if you
set aside enough money.  That's why we've got a red herring--the numbers
can be tweaked.  Moreover, this is not just an idle observation...

There are lots of "methodology mavens" on the loose these days.  They'll
sell you or teach you a way to improve the predictability of your software
projects.  An unfortunately large proportion of them do it by adding make-
work to projects, in a particular way:  They front-end load the project
with paperwork, rituals, meetings, millstones, etc.  What does this do?
	- It increases the total time/budget for the project, providing a
	  way to hide needed time/money.  If things start to get tight, the
	  ritual gets short shrift; the effort gets shifted to real work.
	  You get a safety buffer you don't have to justify.
	- It lets you hire (or assign) the people you're going to need in
	  the later implementation phase early on...and it gives them some-
	  thing to do (push paper) without getting in the way too much.
	  (After this, they'll be GLAD to get to work!)  This allows lazy
	  management to deal with a flat staffing through the project.
	- It adds to the total time/money for the project, so that any
	  error in estimation induced by true risk is reduced in apparent
	  magnitude by the slopfactor.

The next point may come as a radical surprise (or affront) to the academi-
cians (and Adacademicians especially), but:  It's not necessarily best to
produce a schedule which you know you can meet at a very high confidence
level!  Sure, if you're aiming for a hard deadline or bidding a contract
fixed-price, you need to hit pretty high confidence.  But in many cases it
makes more sense to set the schedule at the most probable completion time.
That's the most useful for planning.  For example, in the commercial world,
aiming for a 90% confidence-of-completion time on a schedule might cause
you to decide you can't meet the market window for a product--when in fact
a more realistic confidence level in scheduling will tell you it's worth
the chance.

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.
-- 
+---------+     Dick Dunn    rcd@ico.isc.com    ico!rcd      (303)449-2870
| In this |         4th annual MadHatterDay [10/6/89]:
|  style  |            A Thousand Points of Madness
|__10/6___|