NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/c/16631

Internet Message Format | 1992-11-17 | 2.5 KB

Xref: sparky comp.lang.c:16631 comp.software-eng:4335
Path: sparky!uunet!gistdev!flint
From: [e-mail] (Flint Pellett)
Newsgroups: comp.lang.c,comp.software-eng
Subject: Re: Will we keep ignoring this productivity issue?
Message-ID: <[e-mail]>
Date: 16 Nov 92 20:19:57 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Followup-To: comp.lang.c
Organization: Global Information Systems Technology Inc., Savoy, IL
Lines: 37

[e-mail] (Dick Dunn) writes:

>....  On the
>other hand, we seem to think we've got enough good programmers that we can
>afford to spend them cleaning up code of a sort they'd never write in their
>worst drunken stupors.

>Well, I'm no Van Jacobson, but I've certainly had to spend extended periods
>working on code of a quality for which I would have flunked my first-semester
>programming students 15 years ago.

This looks to me like an area that someone ought to devote some study to:
it would be interesting, at the very least, to get some feel for what
percentage of their time top programmers spend cleaning up after the
others, (or in consulting/teaching others) and then formulate some
methodologies for eliminating THAT problem.  If the top people are
spending half their time cleaning up junk, you have a potential doubling
of productivity right there.  (While it is less of a problem in these
days when it is cheaper to buy a new disk than clean out an old one,
it used to be the case that a lot of time was expended in going thru
disk and deleting worthless junk.  It was often the most valued
people who had to do that, because they were the only ones who had
the judgement and knowledge necessary to be able to sort the good
stuff you needed to save out from the garbage.)

One example of the "cleaning up junk" area: I've noted that one thing
the poorer programmers like to do when they need to do something that
is very similar to what an existing routine is doing is to make another
whole copy of the original routine, then tweak it slightly.  You end
up with 2.0 times as much code to provide 1.05 times as much function,
and often when the good programmer comes back to it they have to spend
a lot of time before they notice the duplicated code and can cut it
down to size.
--
Flint Pellett, Global Information Systems Technology, Inc.
100 Trade Centre Drive, Suite 301, Champaign, IL  61820     [phone]
uunet!gistdev!flint or [e-mail]