From: francis@ircam.fr (Joseph Francis)
Newsgroups: comp.lang.c
Subject: Re: Productivity of a C programmer ? (Close, but no tomato)
Date: 16 Nov 92 17:17:33 GMT
Organization: IRCAM, Paris (France)

In article <1992Nov12.230327.8660@eecs.nwu.edu> travis@eecs.nwu.edu (Travis Marlatte) writes:
>I don't understand the need to look at the source code to establish
>productivity. Actually, I don't understand the need to establish
>productivity at all. It definitely isn't needed to quote future
>projects.

Of course it is. One can write anything, and people on the net
frequently do write anything, or what might better be termed "nothing,
nothing at all".  But to impart meaning is to have a personality which
people regard.  Writing 'need to look at source code [...] isn't
needed to quote future projects' doesn't lend credibility to yourself.
Source code quality should be considered intimately with future
project scheduling considerations. There is a reason for the phrase
"quick and dirty".

>For example, when a hardware engineer creates estimates for a new
>circuit he doesn't say, "I figure its going to have 1500 resistors,
>1000 capacitors, 150 ICs... therefore based on ohms per hour I should
>have this done in 14.6 man-days."

Unless the EE is dealing with VLSI design, perhaps, though you
exaggerate, as could I. Design considerations should, however, flow
from functional element identification - leading in a way to estimates
based on nuts and bolts. If one doesn't design software (I write of
projects) based on sufficient/necessary criteria for final perforance,
and therefore elements to fulfill those criteria (down to details),
then what is is based on? (as follows, I suppose)

>And when the circuit is complete, other engineers don't evaluate it based
>on the number of compontents. They may evaluate its complexity, but not
>directly its component count. Imagine a manager saying, "We're giving you
>a raise. You deserve it. Last year you completed designs with 1M components.
>Congratulations!"

I would suspect the raise would be inversely proportional to the
number of components used, among other factors. In complex systems,
the higher a component count, the more difficult it can be to debug
(except for well-black-boxed systems) and the smaller MTBF. A toy
example: would be the management of hundreds of variables external to a
program functional block is quite different than the management of a
few, and the sheer number of such pieces in a large system induces a
sort of glazed-eye conscious overlooking of their impact.

>When a programmer asks me to evaluate his work, I am not immediately
>interested in the source code. I want to first know

>	- how cleanly does it interact with the other parts of the system.

Divined, I suppose, by looking at tea leaves left after the
Chinese-delivery food all-night frantic coding session breaks.

>	- how well it interacts with the user (if any)

The most important part of any network system, in my mind. And
clearly the most quantifiable, in the overall scheme of things.

>	- how does its processing time compare with ideal

Since we know all software is frequently used until the end of time
the total processing time is much more important than the time that
will be used to adapt and modify the source by others. Also, clearly
quantifiable, since the ideal system is completely characterized.

>	- how does its elapsed processing time fit into the system

Ditto.

>	- how much executable space does it consume

Though I hear with PDP-11/70s under RSX there are shareable libraries.

>	- how much memory does it require worst case

Those nasty 64k boundaries.

>	- what trade-offs were made for code space against time

Why, we made all variables global so we wouldn't have to push them
onto stack to make function calls.

>These are the external characteristics that can be quantified and compared.
>I can compare the results of multiple programmers based on this kind
>of information.

Rather than clarity of code; the ability of other programmers to
support their code (since we know that programmers are lifetime
members of design teams); efficiency; cleanliness of code-interface.
Layering. Orthogonality. Completeness.  Regression-testability.
Portability. And those last fabulous catchwords "Extensibility" and
"Scaleability".

>Then I want to look at the code. If it runs close to ideal in a minimal
>amount of code space but the source code is unintelligible, it's garbage
>unless there is a real need for the resulting performance. But if the
>need is there, then speghetti code can be justified (sometimes).

Yes, most major programming projects I've worked on, when poorly
designed, hired the Q/D (quick and dirty) consulting department and
fired nasty old Q/A. Bad code has a way of living forever, in a manner
akin to 'beating a dead horse', while good code is immortalized,
adapted, cloned, propagated.

>If a programmer cannot provide the above information, then I don't think
>the programmer actually engineered the code. It is more a result of hacking
>together the first idea that had a chance - maybe with improvements done
>after it was once working.
>
>Lines of code and comments only add to readability. They mean nothing
>in terms of productivity. I can take 6 months to engineer an algorithm
>and make it readable in a day.

You left out the smileys. Code like this ends up like T.S. Eliot's
explanation of the meaning of "The Wasteland" - when he wrote it, he
and God knew of its deeper meanings. Now only god knows.

People like this should be forced to work without manuals.

>Why are you all so interested in productivity? If your jobs depend on it,
>then maybe you should find a company that is more interested in real results
>rather than fluff. Can you say 90210? I thought you could.

Its just that not many companies are interested in genii who routinely
use xor's to swap two variables 'cause its faster, and uses less
processor time, and makes for smaller executables, and has much better
worst-case memory requirements, and is lots faster in code-space than
the time-space continuum.

Real results are finished useful projects.

Vaporware is the result of cool demos sublimating in the light of day.



-- 
| Le Jojo: Fresh 'n' Clean, speaking out to the way you want to live
| today; American - All American; doing, a bit so, and even more so.