Re: ada-c++ productivity

[stachour@sctc.com (Paul Stachour)]

>>from the Feb. 11 issue of Federal Computer Week:
>>
>>   "The board upheld a decision by the Air Force to award a contract to
>>    a high-priced bidder based on a measure of productivity that equals
>>    three lines of Ada code per programmer per day.
  ...
> I would like to
> know what in this world could reduce a serious programmer's
> productivity to these levels.
>email: rreid@cscihp.ecst.csuchico.edu

-----

   This question reminds me of the discussion in Gerald Weinburg's
"The Psychology of Computer Programming".  If I remember it right,
it was a discussion between two programmers. Programmer B had just
completed reprogramming a task originally given to programmer A.
A was complaining about the speed of B's code, pointing out that
A's original code was much faster.  B replied with something to
the effect that << But your code isn`t correct.  Mine is. If mine
doesn't ahve to be correct, I can made it as fast as you want.>>

   The point about productivity is that it can only be properly
measured for "correct" code.  And knowing what the characteristics
of the code is makes is correct or not.  For example, suppose I
have a set of C-code.  I compile it on 6 different C-compilers.
It compiles without error, executes, and gives the same "right"
answer on all.  Now I give this code to 7 different programmers.
They each compile, link, load, and execute it.  For those 7
programmers, each of which used a different C-compiler, they all
gave the wrong answers.  Yes, I may have had great-prodcutivity
in my original code.  But if everyone else gets the wrong answers
due to the fact that I don't know about a critical environmental
component, or fail to document it, or fail to note that most
C-compilers for physical-memory multi-tasking systems will not
get the answer right, is my code correct?  And given the time
for all of them to discover it, how much prodcutivity was there
really?

   I can give you a great lines-of-code productivity feature if:

  1)  I can presume all my inputs are correct.
  2)  I can presume all the subroutines I call are correct.
  3)  I can presume that the hardware never flips bits.
      Nor are there any other hardware errors.
  4)  I can presume that the compiler always generares correct code.
  5)  I can presume that I have enough memory and CPU cyles so
      that I can always think "clarity" instead of "make it fit"
      or "do swapping yourself".
  6)  All my users speak English so that I don't have to worry about
      how to handle multi-lingual error messages.
  7)  My cleanup routines will always get called on power-down
      or any other kill-condition so that my disk-data will
      always be consistant.
  8)  The client has a clear, simple, and unabigous specification so
      that I can spend all my time designing and implementing instead
      of trying to figure out what he really needs, instead of what he
      says he wants (which is full of contradictions).
  9)  I don't have to be compatible with existing applications that
      process the same data.
 10)  I have no numerical problems with overflow or zero-division.
 11)  I am working on a small enough project, in one single location,
      that I can get questions answered promptly.
 12)  I am allowed to work with hardware that is documented, instead of
      "new improved hardware" for which no documentation yet exists,
      and I have to play trial-and-error to see what it does now
      (which may be very different next week).
 13)  When I'm forced onto new hardware and software in the middle
      of a project, they are actually compatible with the old.

  All of these, and more, are assumtions that are often false.

  Sure, in the context of a simple, university-level, class assignment
that got thrown away as soon as done, I have great productivity also.
How many students at the university where you go/teach could write a
resuable component for something as simple as a stack?  I'd bet
that 95% couldn't.  I base that on me, my colleages, and those I teach.
I base that on the fact that most hardware can't even do a shift
properly (well, at least the way that the documentation says it does it).

  If one accepts the premise that 90% of good-code is for the conditions
that happen less than 10% of the time (personally, I'll even say 1%
of the time), then one can get a 10-fold increase in productivity by
merely ignoring error-conditions.  And if you buy component code
from a commercial vendor, as we sometimes do, you can make some
pretty big discoveries of bugs.  We bought some code. We've used it
for several years.  In the first year, we found only a few bugs.
In the second year, we really started to use to code, and found a few
mode.  In the third year, we discovered that there were enough 
seldom-happen items not covered by the code that it was not useful.
And so we are re-writing it.  And this time (I hope) we will test it.

  I could go on and on about the groups that I've seen and worked
close-to that claimed to have "great productivity".  A few did.
But most merely turned out code fast.  And that code was full of
headaches for long-time to come.

  Enough for now.

  ...Paul
-- 
Paul Stachour          SCTC, 1210 W. County Rd E, Suite 100           
stachour@sctc.com          Arden Hills, MN  55112
                             [1]-(612) 482-7467