Re: Learning Curve; Software learning percentage.

Stephen J. Turnbull wrote:

>>>>>>"Taran" == Taran Rampersad <[email protected]> writes:
>>>>>>            
>>>>>>
>
>    Taran> I'm hoping that someone can tell me what the statistical
>    Taran> reference for Cost Estimation of *Software* is for
>    Taran> calculation in a Learning Curve calculation.
>
>There's the 1985 book by Gotlieb, _The Economics of Computers: Costs,
>Benefits, Policies, and Strategies_.  A citation search on that might
>turn up something useful.   Fred Brooks _The Mythical Man-Month_,
>Yourdon's _Decline and Fall of the American Programmer_ series, and
>Watts Humphrey's software engineering books contain many references to
>the technical literature where various coefficients have been estimated.
>
>The problem is that most of the relevant studies were done within
>corporations on extremely proprietary data, and you probably will find
>that the data could be used to calculate the coefficient you want but
>it hasn't been done.
>
>    Taran> The main problem with the Learning Curve calculation on
>    Taran> software is 'Number of Units', which, with software, should
>    Taran> be 1 given code reuse (Wright/Crawford). And that's the
>    Taran> interesting part, given licensing. It's probably apparent
>    Taran> where I'm going with this...
>
>No, not at all.
>
>The learning curve as defined by industrial economists is about the
>decrease in cost associated with mass production.  That is, you would
>expect that the cost of blank CD-Rs would fall as they are produced in
>their billions, and this can be fit to production and price data (or
>unit, even marginal, cost data, if you can get it) to produce an
>exponent for the learning curve.  The usual generator is learning-by-
>doing, of which the "muscle memory" associated with a martial art or
>playing a musical instrument is the prototypical example---ie, we're
>talking about _exact_ repetition.
>
>Software engineering doesn't work that way; rather, it's all about
>setting up the conditions under which something like learning-by-doing
>can take effect.  But the learning curve as such has assumed that
>problem away; it assumes you know _how_ to mass produce whatever it
>is, and then allows you to estimate the long-term cost savings from
>implementing mass production.  But we don't even know how to produce
>custom software efficiently yet....  :^)
>  
>
Right. This is the problem, actually. I'm trying to flip this all on 
it's head - where the focus is the learning than the cost of 
manufacturing. Maybe some context will help...

Consider a proprietary operating system such as Windows. Microsoft 
reuses code - objects - within it's operating system and it's 
applications. For example, Microsoft Office makes extensive use of the 
Microsoft Foundation Classes, which are found within the operating 
system. Thus, they do not need to write them. At an organizational 
level, they are 'mass producing' in a respect; they do not have to 
rewrite what they have already written. Of course, this has results you 
can read about just about anywhere, but there it is: They save money by 
not spending, and the money they save is spent on researching new 
objects. The cost for producing the object is paid back over time in 
good *business* instances, and the object diminishes in cost/value as 
the value increases.

An abstract hypothetical learning curve could be derived from that, 
maybe. What do you think?

-- 
Taran Rampersad

[email protected]

http://www.knowprose.com
http://www.easylum.net
http://www.worldchanging.com
http://www.fsc.cc
http://www.a42.com