Conference 7.286::digital

	There is an article in a recent Digital News (or Digital Review?)
	written by Tom Harris (CLT Manager) on this subject. I believe
	he used CMS data to measure the improved productivity in his
	organization.

	Other conferences you could look in would be SIVA::SWENG (the
	software engineering conference) and the Computer Aided SW 
	Engineering conference at CURIE::CASE.

			Alfred

    In our group, the only way we measure productivity is ``are your
    estimates reasonable, and do you get the job done when you estimated
    you would''.  Measuring productivity objectively is really hard when
    the work you do is quite abstract.
    
    Here is an old story from PDP-6/PDP-10 Software.  There was an
    established format for programs on binary paper tapes, involving
    data addresses, data values and start address coded a certain way.
    In order to be able to load all of memory, the program which read
    from the paper tape reader and interpreted these instructions had
    to fit in the registers, and there were only 16 registers.  The
    problem, therefore, was to write a suitable interpreter in 16 or
    fewer instructions.
    
    Several people brainstormed over this for a while, and several
    17-instruction solutions were proposed, but nobody could come up
    with a 16-instruction solution.  Then into the meeting room walked
    one of the senior programmers who had not been participating in the
    brainstorming session, and wrote a 15-instruction solution on the
    blackboard!
    
    (I was not a Digital employee at the time this supposedly took place,
    so I cannot verify the truth of it.  Fortunately, that isn't important
    to my point.)
    
    In this story, considerable effort was expended and the result was
    a solution of the problem.  However, "productivity" was negative, by
    traditional measures: -2 lines of code were written!
        John Sauter  

          <<< HUMAN::DISK$HUMAN_WRKD:[NOTES$LIBRARY]DIGITAL.NOTE;2 >>>
                          -< The DEC way of working >-
================================================================================
Note 1030.3                  Measuring productivity                       3 of 3
BUCKY::FRIEDMANN "moderate extremism"                14 lines  15-FEB-1990 15:15
--------------------------------------------------------------------------------
The Digital Technical Journal, number 6, Feb 1988, contains an article by
Anne Smith Duncan and Tom Harris on Software Productivity Measurements.  The
article is an empirical study of s/w productivity measurement in the 
Commercial Languages and Tools Group at Spitbrook (Central Engineering in N.H.).

Collection of any metrics (including productivity) first requires an 
understanding of the goals of the collection.  Is your customer fairly
sophisticated about software engineering?  You may want to bring in a CASE
consultant to help your customer.  What kinds of productivity information
are they interested in?

The use of CMS article referred to by an earlier reply, if memory serves me
correctly, involved an agreed upon formating of the CMS remark field to
reflect the activity type.  An independent program was then used to perform
tabulation and statistical analysis of the history file data.

I actually think this discussion should be moved to one of the afore mentioned
conferences.

/dan

    The Software Quality Management Group here in Spit Brook has a
    development/tools metrics function.  You can reach them with any
    questions about metrics at SQM::METRICS
    
    I will mail you a report they just issued today.  Hope this helps.

    	Why just Software Engineering?  How about a a tool to measure
    "Engineering"?  Not much difference.  Both turn ideas into things that
    actually WORK.
    
    	Then again, if you are measuring productivity of "programming"
    you can do that nearly as easily as measure word-processing or
    data-entry...
    
    Don

 re: .2

   <<<								The
   <<<    problem, therefore, was to write a suitable interpreter in 16 or
   <<<    fewer instructions.

John,

I never heard of a 15-word bootstrap program. The story I heard at the time
was that the programmers came up with two 16-word programs and had to choose
which one to use. Since these programs would have to be wired by hand into the
doughnut-shaped ferrite cores (remember when we talked about "Core memory"!),
they analyzed the binary code for these two programs and selected the one with
the fewest changes from 0 to 1 or 1 to 0. This meant fewer changes in direction
of the wires wound around the cores and made the ladies who worked the memory
manufacuring line in the Mill more productive.

Now that's measuring productivity!

	/Marvin

    re: .6---My memory may be faulty, but I am pretty sure it was 15 words.
    The program is listed in the instruction set manual for the PDP-10.
    The accompanying text says, correctly, that despite its length it is
    not a simple program.
        John Sauter

re: .6,.7

John,
	Could I be mixing the 10 with the 1?  No matter, both stories 
might be true!

	/M

    .6>which one to use. Since these programs would have to be wired by hand into the
    .6>doughnut-shaped ferrite cores (remember when we talked about "Core memory"!),
    .6>they analyzed the binary code for these two programs and selected the one with
    .6>the fewest changes from 0 to 1 or 1 to 0. This meant fewer changes in direction
    .6>of the wires wound around the cores and made the ladies who worked the memory
    .6>manufacuring line in the Mill more productive.
    
    Sorry,but I've been around awhile and I never heard of DEC doing
    anything like that with cores.Maybe something pre PDP-1...Tom Eggers
    ,Alan Kotok...maybe some help here?
    
    Ken

    The PDP-1's bootstrap was built out of hardware.  Perhaps the PDP-9?
        John Sauter

IBM 7090 bootstraps were wired into the core.  Three instructions, as I recall.

By the early 1970's, hard-wired PDP-11 bootstraps were built out of 32-word
ROM modules (rows of diodes that were removed as needed).  (These, of
course, were customer-configured bootstraps.)  I don't think there were
built-in bootstraps before the 11/40 or perhaps /34 or /70.

Martin.

	Ah, the glories of the technology of the past (seems *so* recent!).
	But, getting back to the base-note, ...

>>  	we definitely don't have any [tools to measure software engineering 
>>	productivity] in use out here in the field (OTHER THAN GENERATION 
>>	OF REVENUE)         [my capitals]

	Well a financial measure sure isn't a bad start!  As the story is 
	told in .6, for example, it seems that the point of agonising
	over the 1x-word bootstrap program was to save manufacturing costs.






	Surely one of the *fundamental* measures of engineering productivity 
	is "what extra income do we get for the money we spent?"  Is that the 
	only measure that matters?  Absolutely not!  But I reckon any 
	engineering group that doesn't include some connection to profit 
	amongst its measures has rather lost track of the meaning of business.

	Jim

    Generally productivity is useful only in a relative sense. Once you
    have a method of doing something (and a reason as well) one does a cost
    accounting (or time accounting or material accounting) of the method.
    Along comes engineering and develops a better way.... according to one
    of the accounting methods above.  The ratios of new and old are the
    useful meanings of productivity.
    
    I realize this has implicit assumptions. The original method had some
    value added and a target customer segment belief in 'fair price'. These
    are assumed to remain.
    
    So, if you believe this, there are no generic productivity measures for
    engineering.  Each will be oriented toward the task at hand.
    
    Regards,
    

    I believe the PDP-15 is the cpu which DEC include a hardwired
    bootstrap.

    The PDP-1 had a hard-wired bootstrap that wasn't in memory anyplace. It
    read paper tape.  Each 18-bit datum had an 18-bit address.  What was
    usually done was to punch a checksumming loader at the beginning of the
    tape.  The hardware "read-in mode" loader would be started with a
    console switch. It would "read-in" the checksumming loader and then
    transfer to it.  The rest of the paper tape would consist of
    checksummed blocks with a starting address at the end.

    Note .2 is correct.  The PDP-6's loader was the result of a program
    bumming contest that was lots of fun but only marginally productive in
    any sense.  Dave Gross (who still works at Digital) won it by finally
    removing the last two instructions so even the temporary variables
    could reside in the accumulators and not have to be written in core
    memory. I think this is described in the ldpsci::dec_history notes
    conference.

    I believe note .6 is wrong. I was personally there when this loader was
    written, and I don't recall ever hearing the story about minimizing the
    total number of 0-1 and 1-0 transitions. The loader was keyed into
    memory far more than once, but I don't believe it was ever wired into a
    core memory.  The PDP-6 had a "shadow" memory "behind" the 16
    accumulators, but that memory was just 16 locations of a normal 16K
    bank.

      The PDP-15  also had a paper tape hard-wired bootstrap that
      wasn't in memory.