Re: Academic research aimed at improving programmer productivity?

From: Edward G. Nilges (spinoza1111_at_yahoo.com)
Date: 01/05/04 

Date: 4 Jan 2004 22:02:24 -0800

"Brandon J. Van Every" <try_vanevery_at_mycompanyname@yahoo.com> wrote in message news:<bt9sui$4r385$1@ID-207230.news.uni-berlin.de>...
> "Edward G. Nilges" <spinoza1111@yahoo.com> wrote in message
> news:f5dda427.0401040314.2bf14f49@posting.google.com...

First of Brandon, welcome to this ng. A word or two of warning.

Joe "nuke me Xemu" and Randy Howard have dedicated many of their posts
to personal attacks because something I said may have wounded them.
They seem to be good technicians but lack social grace notes in some
regards, in my opinion and my opinion alone.

Richard Heathfield is very knowledgeable about C and indeed the lead
author of a book. However, his focus is narrowly on programming and
would not be (in my opinion and my opinion alone) qualified to address
your very broad concerns, which I share: I have seen numbers, in the
very trade journals that promote large scale enterprise systems, that
show a 75% failure rate in these systems.

Richard Heathfield is also a case of woundedness but men, techncal men
in particular, sometimes lack a language for accessing their pain or
that of others: USA president Bill Clinton was hated because he had
this language.

This is all just my personal opinion.

> >
> > "Productivity" defines the relation between programming and management
> > to the disadvantage not only of the programmer but even of management.
> > It defines the problem as de field hands, laboring out dere in de
> > field in de hot sun, while ole Massah sits with a julep in his hand
> > and calls out to de hands, "y'all work harder and more productively,
> > now, y'heah?"
>
> I agree that this is often what managers mean by "productivity," but that's
> only one definition, and I feel perfectly free to define a different one.
> To wit:
>
> Programmer Productivity (n) - the ease by which *one* programmer can
> accomplish a lot of work.
>
> This is the definition I'm interested in. Note that it is individualistic,
> and does not consider whether sacrificing for "the good of the group" would
> be more productive overall. I'm not really interested in a workgroup's
> total aggregate output. I'm interested in whether individuals are happy and
> achieving significant, major results on their own. I think focusing on
> programming as a team activity is one of the major problems of industry. It
> carries the embedded assumption that there will always be 8 guys to bang on
> some piece of *** API. So when an API is tractable in the hands of 8, it's
> done. Shipped!
>
Interesting view. Well, to accomplish significant results, people need
a humane working day and you might want to do a Google, Amazon and
Yahoo search for "extreme" programming which encourages people to work
in small teams of n>=2. Indirectly this limits the working day to 8
hours and many companies have found surprisingly higher rates of
productivity in the shorter hours.
 
> > Furthermore, I have too much respect for universities to think they
> > should be concerned with programmer productivity. Instead, I'd rather
> > they form a CRITICAL theory of computer science which examines as do
> > critical legal studies how technology is biased towards the needs of
> > the well-to-do.
>
> But what are the practical outputs of such a stance? I don't need some
> academic to inform me that yes, there's something to bitch about. Now,
> maybe *I* don't need to be so informed, and maybe it would indeed be
> valuable to inform others who aren't historically aware. But standard issue
> Marxism accomplishes that purpose, so I don't see why we need a Marxism
> specific to technology.
>
Standard issue Marxism, I'm sure you agree, gets people killed at
worst. At best it produces the pettiness you see in this ng (which
isn't produced by Marxism, for sure) as in Stalin's mistreatment of
Lenin's widow after Lenin's death.

Standard issue Marxists in fact began to rethink Marxism long before
neo-conservatives. As early as 1920 sailors and technicians at the
Kronstadt naval base in the Soviet Union, who were Marxists, demanded
greater control of production. Later on revisionist Marxists such as
Adorno pointed out that standard issue Marxists were making the SAME
mistake as conservative business managers when they "reify" ideas,
making, in my own example, a ridiculous metric such as lines of code
ersatz for productivity.

This may seem to be a far-fetched comparision but if you read how
Soviet managers fulfilled their Five Year Plans you discover a strange
resemblance to the way in which MIS managers accomplish their goals.

What you appear to be saying is that yes, life as we know it sucks,
work sucks, but within the defined context, there must be solutions
that will allow us to complete project A so we can get more work
loaded on top of us.

But if Parkinson's famous law is correct, there may be no solution. As
worker bees, we free up time (say by converting from DOS to Windows)
only to see as does the roving hiker in Yosemite, more weary miles to
walk before we sleep.

Technology genuinely enables us to be more productive in your sense
but in an invisible way. When I started studying compiler design
theory in the early 1970s, building a compiler was rocket science,
today it is easy, both because of compiler design tools but also owing
to better GUIs...simple things like that.

 
> What I need from academics, or industry, or someone, are *SOLUTIONS*.

I think with all due respect that the Star Trek idea of simply talking
to the computer is not on for serious and for mission critical
software. The lesson of driving a simple car is apropos.

If the technical ideal was indeed a "solution" in which we did not
have in some way to think in an orderly fashion about the mastery of
the external world and the technical devices which exist in the
external world, then by now, surely, we would have...a car we could
drive when soused to the gills.

That would after all be, would it not, the ultimate fun car, one that
literally took over in a continuous fashion as it measured your BAC.
At ten tequila shots, for example, it would probably let you press the
accelerator pedal but only at stoplights to impress girls.

"AI" is pure and simple a demand to be eliminated from technical
consciousness while enjoying its benefits, and the demand is a self
contradiction; French sociologist describes it as "science without the
scientist". Sure, if we board the Moon spacecraft and fly to the moon
while getting smashed on Scotch miniatures, we have accomplished the
ideal of getting to the moon, of somehow "using" the technology
without having to "think".

But as a necessary (in Kant's sense of the "synthetic apriori") truth,
there is SOME agency involved and it isn't us. We're a passenger (who
the stews are gonna cut off if we grab their backsides) and the people
who are the real "users" of the technology are the fly boys up front.
We sorta kinda hope that they are taxing their brains and not
themselves having a few blasts. Now don't we.

Forgive my boozy levity (I am in fact sober as I write). I am quite
serious that the whole AI thing should not be dignified or pursued in
any way because a reading of The Critique of Pure Reason shows us that
consciousness is necessarily dual and consists of a subject who must
be equal to the demands of the object.

AI demands the impossible because it wants to depart agency and what
Kant meant by being-a-subject. If en passant you merely bark
"computer, land on mars" after having a few, the AI will at some point
land on mars when you wanted to land on venus.

There's a NECESSARY point, implied by the pure capability to discuss
the possibility of its nonexistence, at which the automated system
fails as compared with the "system" comprised of human needs.

Kant establishes, not this specific point (for the technology of his
time was primitive) but a point which implies it and which, in an
important way, it is impossible to think outside. And you Kant read
the Critique when drunk or stoned.

>
> > But I agree with much of your post and I applaud your bad temper.
> > Entirely too many people get sucked in and wind up thinking of the
> > deficiencies of their tools in a positive light.
>
> The other thing I'm wondering, is whether industrial psychologists have
> studied techie rituals of self-validation.

Gerald Weinberg comes to mind. However, and it is an important point,
Weinberg was a real programmer with some psychological training.
Industrial psychologists are in my view completely not qualified to
study working people who have, I think, the right to narrate their own
lives. Industrial psychologists employed by the state made a mess of
the former Soviet Union, and in America they are kept on a leash.

>
> > But in the last analysis, I think your Star Trek idea of saying to the
> > computer, "computer, unsheath the main blasters and fire the retro
> > rockets" without thinking (don't make me think!) is with all due
> > respect, folly.
> >
> > I mean, there you are, halfway between Jupiter and its moons, with
> > nothing about you but the terrifying prospect of outer space and
> > instant death should you screw up.
>
> But I didn't say I was going to use the Computer in that way, for a life
> threatening mission critical task. Using the Computer on the holodeck to
> design a game would be perfectly valid, and I could certainly tolerate some
> time spent saying, "No no no, do it *this* way." I assume that for any

But that's what we do. We change things using a programming language.
The fact that the programming language is formal and explainable is
part of the charm of the activity as opposed to talking to our wives
and our sweethearts, because in the latter case the results are less
predictable.

[Another bad joke comes to mind: Q: why is a Windows dialog box like a
wife: A: because you can only click OK.]

In the only MEANINGFUL sense of AI, real programmers have been
creating AI, with their maddening slowness, since John Backus and the
IBM Fortran team optimized three registers using Monte Carlo
simulation to guess at the best pattern of allocation.

One sees the call for "real" AI consistently coming from people who
cannot program who are sad about that fact. They should count
themselves fortunate for their jobs are easier. Mamas don't let your
babies grow up to be programmers.

> complex task, interaction with a Star Trek Computer would be fundamentally
> managerial. Sapience only gets you so far. Even with blinding speed, there
> are only so many problem permutations one can consider per unit time, and
> someone has to decide which features should be included or excluded. A
> film, for instance, isn't a kitchen sink. It's a conscientious selection
> and rejection of all sorts of things.
>
> The basic issue you raise is managerial: do you Trust your Computer? Are
> you willing to Delegate authority for decisions to your Computer? When yes,

I am certainly willing to have my computer play me Sambre et Meuse
first thing when I need to get up, and I trust it to do so. I do not
trust a computer to tell me that George Bush is elected next November.
But note that the trust you specify implies a forced or nonforced
agreement on common values, as where the Klingons serve Captain Kirk.

> when no? If no, are you saying that because it's practical or a good idea,
> or just because you're squeamish about giving up perceived control? I can
> guarantee you that current spaceships aren't inherently trustworthy.

We know that. But Challenger and Columbia were death traps because of
poor managerial decisions and forcing good engineers to be silent.
This is a problem that implies we need less science, especially
objectifying behavioral science, and more wisdom.

> Nevertheless, I don't see how you're going to effectively fire the rockets
> manually, that sounds like a good way to die. Rather, you'll still be using
> some automated system, just a lower level of automation than some other kind
> of decision making. And it may not amount to anything more than, "Not
> Invented Here, I want to die My Way [TM]."

Well, we all gotta go sometime.

I would expect the next entrepreneur with dreams of private space
exploration to use automation, of course, in part because the physics
of space travel are relatively deterministic.

>
> > Programming SHOULD be hard. This way you take thought about the needs
> > of the user and society as a whole. It should NOT be some Tom Clancy
> > whiz bang.
>
> I disagree. I think Programming should be Reliable, and Productive. I'm
> not interested in that being difficult to accomplish; rather much the
> opposite.

Why is that? Brain surgery is hard and getting harder even as it is
more productive. Why should programming be something so easy to do?
>
> > The ONLY success stories to my knowledge today are in mixed-gender
> > groups at NASA which do everything by the book and nine-to-five and
> > certain "extreme" programming ventures which also stress the need to
> > limit the working day.
>
> Yeah... hmm... that definitely *is* one of the strategic issues. As long as
> managers, or even the workers themselves, feel there is some great honor in
> burning tons and tons of hours, then no productivity solutions will be
> sought. There's a tiny handful of enlightened companies that lock the doors
> at 6 pm, SAS Institute in Research Triangle Park, North Carolina being one
> of them.

Interesting.
>
> > But any R & D on people behavior is doomed for theoretical reasons
> > that were outlined by Gerald Weinberg in 1972. People are too ornery
> > and as such do not present "fixed targets" who can be "forced" to be
> > "productive".
>
> That's why I'm not much interested in the "people behavior" side of the
> problem. I can already control that to some degree by working for myself.
> There's a technical component to the problem, and "bad SDKs" is certainly
> one of the main components.

I just got done building some IL code generation into a compiler for
.Net and I blew a gasket when the tool tip for an instruction said
that Ret makes the top of the CALLER'S stack available to the CALLEE.

These sorts of errors in mere writing make me want to "creep away like
a tired child and weep away a life of care" for it's possible that
that's what the Ret instruction actually does. Fortunately, when I
invoked the dynamic method the value of the compiled expression was
returned to the CALLER.

Poor technical writing offends G-d's law and man's because it is an
assault on the language. I also refer to "indexes" that give you 500
results including paths to information on Foxpro.

You should also read in this connection a book by law professor Cass
Sunstein called Republic.COM who alerts us to a significant downside
in the consumer AI dream, for part of the consumer AI dream (retailed
by Bill Gates in The Road Ahead) is extensive filtering, as where I
would say to my computer, "computer, don't ever, again, tell me
anything, at all, about goddamn Foxpro". I was invited in 2001 by
Princeton Univ press to join an online discussion with Sunstein and
Mike Godwin.

Sunstein pointed out that extensive filtering and agent technology
could close you off to information you did not know you needed to
know. Politically, he discussed how filtering in political discussion
groups leads to "cascades" of false opinion (this phenomenon appears
in this ng).

AI could limit possibilities in this way.

One example occured in the CNN network during the Iraq war, for
stories filed by journalists were examined for key words and phrases
that implied that the justification for the war was airtight or that
there might be problems after "victory", and purged before being
edited.