NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/software/4250

Text File | 1992-11-12 | 6.7 KB | 160 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!george.arc.nasa.gov!lehman
From: [e-mail] (John Lehman -- GDP)
Subject: Re: Will we keep ignoring this productivity issue?
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: NASA Ames Research Center, Moffett Field, CA
Date: Thu, 12 Nov 1992 18:14:03 GMT
Lines: 149


...
 >> Article: 10236 of comp.software-eng
 >> From: [e-mail] (Dick Dunn)
 >> Subject: Will we keep ignoring this productivity issue?
 >> Summary: CAN we afford to ignore it?

...
 >> 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?


However the question of "How can the vast resources of the multitude
of ordinary or only-moderately-skilled people be tapped?" is also
worth pursuing.

Most people could be far more productive than they currently are,
and what is holding them back is poor teaching, poor management
by their bosses, and a wide-spread competitive (as contrasted to
cooperative) ethic.

But, maybe you would say, their increase in productivity would not
surpass a factor of 2, anyway, while greater gains are to be made
by the highly-skilled (or possibly highly-intelligent) few.  Even
if it is true that they can never achieve more than a factor of
2 gain (which I doubt), their vast numbers more than make up for
this supposed limitation.  __Productivity per person is one thing;
productivity per organization or per nation is another.__  (Similarly,
long-term productivity is not the same as short-term productivity.)




 >> In fact, I suspect we'd even be better off just letting those who can, do,
 >> and not pretending that those who can't, can.  "Negative productivity" is
 >> too well known; if we weren't sending some fair fraction of our best pro-
 >> grammers off to clean up the disasters created by some of our worst pro-
 >> grammers, we'd have enough real skill to go around.
 >>
 >> [To forestall some of the obvious criticism: I refer to a "programmer" as a
 >> person who constructs programs--the whole things, doing what they're
 >> supposed to do, with all the associated documentation.  I don't mean a
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 >> "coder" or a hacker of binary arcana.]


Well, there are people who are commonly known as
very good, effective, talented programmers, who
_almost_ fit your definition.  They don't document
their work well however.

I thought good doc'n is rare, and that that's why
the people who are really good at writing code
are so hard to emulate, and why ordinary people
have such a difficult time stepping up into
programmer roles.

I thought master programmers were usually people
who achieved their lofty positions of power (i.e.,
power through skill, knowledge, and experience)
partly by not wasting their time educating others (e.g.,
they don't spend their efforts in leaving behind
good documentation).



Perhaps you are right; but, I don't think good programming has
to be all _that_ difficult that only very few people can
learn to make a worthwhile contribution doing it.

Whatever terms we use, it doesn't matter so much who is called a
programmer, as it matters what useful work is being done.  Someone
else in comp.software-eng recently wrote that people can be pro-
ductive using applications like spreadsheets doing things that
_used_to_ require handholding by a "programmer".

(O) From: [e-mail] (Blair P. Houghton)
(O) [expletive deleted]
(O) How about we design some machines to do the coding for us,
(O) now that we have a standard for C?

Yes; I interpret this as:  "programming" is just a part of
something larger and more significant.



Even as a mere ordinary hack I have been able to write some
useful programs.  One of them was well-used by scientist groups
on a super-computer facility, for over a year, until that
computer was removed (the program's purpose was operating-system
dependent.)

And, before that, working more or less in the same job, a few
years before, I _had_ been a highly-skilled specialty pro-
grammer for a short time and proved it by writing a set of
programs that used two widely different computers to trans-
late information from a 3rd widely different computer.  I don't
now have access to any of those 3 types of computers, either.
And some of my skills have eroded with non-use.

I do not know for sure whether I am now a mere ordinary
programmer, just possibly at times being the sort you
may be tempted to call "negatively productive", because
programming (or, the kind of programming which I am trying
to learn) is really that difficult, or because I am in the
"wrong job", or [ommitted for political reasons], or because
I have been too lazy too much of the time, ... or whatever.
The fact remains that I still love programming; and I don't
care to have my programming power usurped by an elite of
programmers more skilled than I.  (And, this may be relevant to
your cause of achieving productivity, if many programmers
think as I do.  Moreover, it could be that the market will often
prefer products which they can understand and modify, made by
people similar to themselves.  Sometimes the masses don't want
a genius:  for example they elected Reagan U.S. president.)


And now, I've thought of another answer to the question of what
makes really good programmers tick.  It's a matter of work timing,
scheduling, and dependencies.  The best programming is done by
someone who is following his/her own internal schedule, not someone
else's schedule.  The best programming is done by someone with
24-hour access to the relevant computer systems, and who doesn't
have to wait on someone else before s/he can work.  Much, maybe
most, of my best work, programming _and_otherwise_, career, hobby,
paid, or unpaid, was done on an odd schedule, doing things that no
management even knew about, and taking care of the details myself
rather than relying on a secretary or anyone else.  Moreover, a lot
of my best work has been unsupervised:  I need a lot of space, to
think well.

On the other hand, it is true that pressure, as in taking a
timed exam, sometimes produces effective thinking.

A third factor we must take into account is the ability to
cooperate and integrate with others, such that strangers
can maintain one's code.  The simplest, maybe best, answer
to this, is documentation.

If we could integrate the above 3 paragraphs into a way of
programming or "software engineering", we would have taken
a big step forward into being a more productive industry.




[e-mail]