From: hammondr@sunroof.crd.ge.com (Richard A Hammond)
Newsgroups: comp.lang.c,comp.software-eng
Subject: Re: Will we keep ignoring this productivity issue?
Date: 13 Nov 92 14:35:29 GMT
Organization: GE Corp. Research & Development, Schenectady, NY

In article <BxMuBK.ArM@inews.Intel.COM> nsridharan@faois.intel.com (Sridharan) writes:
>In article <BxKEv9.4K8@cs.uiuc.edu> Rob Hasker, hasker@cs.uiuc.edu writes:
>>On what sorts of projects?  While there might be a difference for small
>>projects, it certainly wouldn't be clear that there would be a
>>difference for large projects.  ...

>Ahem ... the project wouldn't BE BIG if you used the "very good" people, would
>it?

>Try a hypothesis:  What if .. just what if .. the famous 80-20 rules works.
>Examples: 80 percent of the function comes from 20 percent of the code
>	80 percent of the value comes from 20 percent of the effort
>	80 percent of the result comes from 20 percent of the people (in a large
>project)
>	and etc etc
>So, if an ordinary programmer is a slave to the ordinary world
>and if a talented programmer understands how to apply the 80-20 rule and can
>get 80% of the most valuable work done in 20% of the effort; and  
>if a "gifted" programmer is one who can apply the 80-20 rule twice over - and
>can get 64% of the value with only 4% of the effort
>- Would this account for the variability in productivity?

>Since the argument is generic - you might say why then don't we see the same
>in carpentry or shoe repair.  Aye, then , the subject matter is not so ELASTIC
>and one cannot effectively do much in that subject.

NO!!  The reason we don't see that in shoe repair and carpentry is that nobody
wants an 80% finished job and the fact that it is 80% finished is obvious by
inspection, even to the untrained eye.

The problem in software is that we, more specifically management and sales,
can't easily tell the difference between 80% done and finished.  I know that
my code has stubs for all the error recovery, for example, but it appears to
function just fine in a demo, because I avoid the operations which cause
errors.  So, I was very productive the first 20% of the project.  The demo
looks great, but there's a lot of work in getting the regression testing
set up, filling in the error handling, documenting the internals, ...

For example, I'm working on a project which is building a multi-processor
in a VME rack.  I'm attempting to add support for a new type of board.
The existing system has two modes that a board operates in, master & slave.
The effort to get the new board up as a slave was maybe 20% of the work.
The problem is that my own system has only the new boards, so one has to
function as a master.  That's taking much longer, there are significant
assumptions about the architecture of the hardware built into the code and
the new boards no longer fit those assumptions.  Besides the hardware, the
problem is that the whiz kid coder, who got the job "80%" done, didn't
comment the code well and spread the functionality and dependencies over
a number of modules, as well as depending on magic constants embedded in
battery backed up RAM, specific versions of ROMS, ...

As someone else already pointed out, on a really large project the actual
coding is a small fraction of the total effort.  Most of the effort is the
documentation, design, integration and testing.  The speed of the coders
would make very little difference, and if the code was not easily maintained
then integration & test might take more time than was saved in coding.

Most of the fast coders I've seen have been the ones who neglect the non-code
aspects, i.e., design, testing, documentation.  That's fine for small demo
projects but not for large or long lived projects.

I think the 10x or more performance difference is a myth from not measuring
all the relevant issues, because it is so difficult to look at software and
say you've only done 80% of the job or 64%.

Rich Hammond