From: mcgregor@netcom.com (Scott Mcgregor)
Subject: Re: Will we keep ignoring this productivity issue?
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Thu, 12 Nov 1992 05:58:44 GMT

In article <1992Nov11.195515.20763@cs.rit.edu> mjl@cs.rit.edu writes:
>In article <1992Nov11.173103.15814@blaze.cs.jhu.edu>, wilson@rhombus.cs.jhu.edu (Dwight Wilson) writes:
>|> In article <1992Nov11.055130@eklektix.com> rcd@raven.eklektix.com (Dick Dunn) writes:
>
>|> >How *can* we afford to be off pondering complexity metrics, bantering about
>|> >25% changes, gaping in awe at the occasional arguably-possible factor of
>|> >2, when there's this sort of fundamental difference that's been staring us
>|> >in the faces for the past several decades?
>|> 
>Well, Bill Curtis of the SEI (formerly MCC) talked about this at ICSE-13
>in Austin.  His analogy was that of running: Ben Johnson on steroids can
>run 100 meters in approx. 10 seconds.  Any person who is not physically
>disabled can do the same in < 30 seconds (even in high heels).  This is
>a 3:1 differential -- against which a 20:1 differential does seem quite
>extraordinary.
>
>Note that the 20:1 is not Donald Knuth vs. a student in Intro. Programming.

You typically see this kind of variance in ability in arts and other
creative endeavors. This is one reason why you see "the star system"
of management and boom and bust cycles in many art/creative
industries: A single Elvis, or Spielberg can make or break a company. 

Comparing Donald Knuth to an Intro
Programming student may seem unreasonable as comparing a master
mechanic and an journeyman and an apprentice.  But in many programming
shops there really aren't such clear distinctions in titles. Everyone
is a software engineer or member of the technical staff.  So such
comparisons sometimes do get made.

However, even though there may be individual differences of a factor
of 20, that doesn't mean a project cost is uncertain by a factor of
20. First of all, you probably already know who you have working for
you and what their capabilities are. So you are estimating around
their variance, not the entire possible range.  Moreover, as projects
get large your tend to have more people. This tends to drag you down
toward a norm or worst common denominator (if there are many
dependencies). Indeed large projects can often be more accurately
estimated than small ones, because the errors tend to cancel each
other out, or are biased to the worst case (again if the dependencies
are common).  This can cause high level managers to actually estimate
fairly accurately for the whole.  Sometimes that encourages them to
expect the same level of precision for the smaller subprojects, but
ironically there is probably MORE variance there. (This is not limited
to software--a company may be able to estimate the total number of bad
widgets in a year accurately to .5%, while their daily variance can be
a factor of 20 from a good day to a bad day. If the errors are
distributed randomly they may cancel each other out).




-- 

Scott L. McGregor		mcgregor@netcom.com
President			tel: 408-985-1824
Prescient Software, Inc.	fax: 408-985-1936
3494 Yuba Avenue
San Jose, CA 95117-2967