Review of Steve McConnell's AFTER THE GOLD RUSH
Al Dunbar
about the actual book it purports to review? Is the book as much about
"bricolage" as this article is?
All I can tell is that Mr Spinoza (?) does not like the book. I cannot tell
from his rant exactly why this is the case, or why I should share his
opinion.
/Al
<spino...@my-deja.com> wrote in message
news:901k5k$pm7$1...@nnrp1.deja.com...
> Steve McConnell, AFTER THE GOLD RUSH: Creating a True Profession of
> Software Engineering. Redmond, WAS: Microsoft Press 2000.
>
> Since the 1970s, books like After the Gold Rush have been frequent and
> unchanging. They notice that most software is developed using
> techniques that are apparently what the French call bricolage, on the
> face of it rules of thumb rather than the more scientific principles of
> traditional engineering. They then urge greater maturity upon software
> developers in an hortatory fashion.
>
> What we need to realize is that software engineering is a science of
> man. Its mistake is to transfer the objectification of nature to human
> behavior, thereby becoming, in Nietzche's sense, a form of truth/power
> and a tool for domination.
>
> There is nothing wrong with Nietzchean truth/power and I don't mean to
> reject Nietzche's epistomological discoveries. But there is a real
> problem with truth/power that denies its power component.
>
> C. S. Lewis pointed out that Renaissance science was not so much a tool
> for the disinterested domination of nature as a magician's tool for the
> control of people, and shortly after Lewis, Thomas Kuhn confirmed this
> from within the scientific establishment. Francis Bacon was not only a
> disinterested scientist but also heavily involved with the politics of
> his era and the desire of the Tudor magnates to bring England's people
> under centralized control.
>
> Nonetheless the software engineers believe, by reducing what they
> regard as the bricolage of the traditional computer programmer and by
> increasing the use of empirical tools and visual aids, software
> engineering will then succeed in the manner of traditional
> engineering. Power, they believe, will realize truth, as long as the
> subordinate software engineers and "coders" can be persuaded of the
> truth and kept ignorant of the power.
>
> The rhetoric presents a "new, enlightened, scientific" way of
> developing software and it is opposed to the "old" way of doing
> things. The problem with this is that if you know software history in
> any detail, you discover that a number of different types
> of "bricolage" were used, varying (much like software engineering) from
> bad ideas to good ideas, including the use of high level languages, and
> any number of efficient algorithms.
>
> Admiral Hopper, for example, discovered in the 1940s that the computer
> itself could be used to develop software. This seminal idea was of
> course recognized, but not at the time Adm. Hopper reported her
> discovery.
>
> At the time, many people regarded her discovery as bricolage and as
> unworthy of much note, insofar as the discovery was noted at all. The
> reception of an innovation as "engineering" or "bricolage" depends on
> social networks constructed in detail by power.
>
> In a similar fashion, the "structured programming" guru Edward Yourdon
> gave as an example of the bad, old, bricolage an unnamed programmer who
> he said had said "Go tos are bad." The problem was that what Yourdon
> was reporting was a letter from Prof. Edsger Dijkstra, now at the Univ
> of Texas, to the Communications of the ACM in 1968 that triggered the
> structured revolution (which Yourdon privatized and exploited.) Here,
> Yourdon neatly reversed what one would expect to be the truth/power
> relation between himself, and Prof. Dijkstra because Yourdon
> capitalized the idea whereas Dijkstra preferred a less powerful
> academic position.
>
> Today, bricolage has continued to produce success. Linus Torvaldys'
> bricolage proved that even operating systems could be fabricated by
> individuals with no power relations between each other.
>
> The praxis of actual computer programmers varies widely. However,
> software engineering mavens think it's all bad praxis which, they
> claim, should be more controllable by "normal people", defined in
> America as management, and management-oriented.
>
> "Normal" people seem to be those who more or less willingly adapt to a
> life structured in detail by power. To take one example, the "normal"
> software developer accepts without discussion the capillary power
> relation known as "going to work", involving so often exhausting and
> meaningless daily drives from point A to point B in order to satisfy
> the undiscussed proposition that (a) the corporation needs to watch him
> work, because (b) absent this Panopticon, the employee would
> immediately assert the converse power relation known as goofing off.
> Of course, this misses the very idea, absent as it is from a network of
> power, that one might like to work.
>
> Software engineering assumes two propositions, one of which is true,
> and the other, quite false. The true proposition is that developing
> large software systems is hard. The false proposition is that people
> must be forced to work at this task and that there is no personal,
> subjective, joy of creation.
>
> For example, Steve presents as a sort of model of software development
> in the beginning of the book the building of the Pyramids. He does not
> question the value to society of sarcophagi exalting the vanity of
> Pharaoh. Nor does Steve question the value to society of software
> sarcophagi (eaters of the dead) erected as monuments to CEO vanity.
> This is not to downplay the necessity of large scale software. But it
> is to show that perhaps Pharaoh's slaves did not develop, in the up and
> coming Yankee fashion, clever tools to do the job not so much of a lack
> of knowledge, as a lack of power, and a learned unwillingness to get in
> trouble with the overseers.
>
> Early programmers developed many techniques that newbies have yet to
> learn properly. Programmers were only accidentally members of a guild,
> and this "priesthood" steadily expanded. New monks may have been
> occasionally whacked upside the head for their own good, and users
> demanding the logical equivalent of cold fusion have occasionally been
> sassed, even when they were CEOs: the disruptive backtalk, not the
> bricolage, was the real problem.
>
> Instead of a "priesthood", there was that rarity, the career open to
> talents. Programming has long represented "some way outa this place"
> to people from broken homes, minorities and women. But after years of
> struggle, these folks find social relations unchanged, and they view
> top-down rhetoric about "software engineering" with suspicion and
> hostility. But because they don't have the tools to organize these
> thoughts, this becomes a populist programming anti-intellectualism
> which is part of the problem set, and is marshaled by management to
> resist Steve's goals.
>
> It is simply not likely that even a licensed software engineer will be
> able to hold up a development project in the way that Steve describes,
> by refusing to sign off. Steve takes as frozen and given traditional
> professional/organization power relationships, including that of the
> doctor to his hospital or HMO and that of the lawyer to the megafirm,
> and Steve commits a naturalistic fallacy, for for the same reasons
> programmers cannot seem to professionalize, doctors and lawyers are
> being steadily reduced in power by the same forces programmers face:
> those of cost accounting and naked authority.
>
> The programmer will always represent a scandal: the scandal he
> represent is so unspeakable that it only appears in old myths including
> the Nibelunglied with its account of the relationship of systems (the
> laboring gods who built the palace of the new gods and who wanted to be
> paid.) To be second nature, the administered world has to break this
> nexus and it has and will use all methods up to and including
> liquidation of programmers as a class; for example, researchers have
> found that many "programmers" spend their days doing anything but
> writing code.
>
> Steve does not have much respect for computer science which to me is
> closer to original programming praxis and he feels that enrollments are
> declining in CS because the so-called "market" of prospective students
> shrewdly perceive writing compilers and learning graph theory as
> valueless. This ignores the fact that this market by definition
> doesn't know what it needs, and it also ignores the fact that many
> software products are indeed at some level formal languages. Their use
> demands at a mininum an appreciation for what Dijkstra has described as
> the cruelty of symbolic manipulation. Their fabrication does indeed
> involve at various times the writing of compilers and the
> understanding, at the level of theory, the idea of graphs.
>
> The "software engineer" may very well go to work believing that
> computer languages from SQL to various fourth and fifth generation
> proprietary languages are now so powerful that they understand, in the
> manner of human languages, subtle shades of meaning and all stupid
> errors. But these folks will also, courtesy of lack of humanistic
> culture, fail to grasp just how vast human capability for
> nondenumerably large shifts in meaning can be.
>
> They will be, in other words, modern barbarians of an administered
> world that will not see what it is about, and that will regard human
> creations blasphemously as a second form of nature, more controllable
> by empirical techniques than by logical analysis. What will result,
> and what has already resulted, is more domination of man by man, and
> more "I'm a software engineer, and you're a mere coder." Steve, after
> Code Complete, I expect more from you.
>
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
spino...@my-deja.com
Jason Stokes
>Is it just me, or does this post somehow fail to give any real information
>about the actual book it purports to review? Is the book as much about
>"bricolage" as this article is?
>
>All I can tell is that Mr Spinoza (?) does not like the book. I cannot tell
>from his rant exactly why this is the case, or why I should share his
>opinion.
It's a fairly standard poststructuralist English Lit composition with nods
towards Foucault, Nietche etc. Particularly incongruous in a book about
software engineering, methinks.
Patrick Logan
"Jason Stokes" <js...@bluedog.apana.org.au> wrote in message
news:slrn929a1...@valis.local...
Which illustrates his point, I fear.
--
Patrick Logan
mailto:patric...@home.com
Jason Stokes
wrote:
>"Jason Stokes" <js...@bluedog.apana.org.au> wrote in message
>news:slrn929a1...@valis.local...
>Which illustrates his point, I fear.
Hmmm?
I can't see why a software engineering book would want to address the kinds
of things he's talking about in his review, or have any relevance to such
issues. A programming book is about on the same level as a book on
carpentry as far as social commentary is concerned.
spino...@my-deja.com
"Al Dunbar" <Al_D...@HoTMaiL.com> wrote:
> Is it just me, or does this post somehow fail to give any real
information
> about the actual book it purports to review? Is the book as much about
> "bricolage" as this article is?
It's just you, Al. The review is not meant to be a "consumer guide",
or ersatz for reading the book. For that, plenty of information is
available on www.amazon.com and www.barnesandnoble.com.
The review is instead critique that airs views about "software
engineering" that seldom see print.
Sorry you did not get value from the review, but if you do not share my
disquiet about the ways in which some software engineers at one and the
same time use and diss academic computer science, and programming
bricolage, then the review wasn't meant for you.
>
> All I can tell is that Mr Spinoza (?) does not like the book. I
cannot tell
> from his rant exactly why this is the case, or why I should share his
> opinion.
>
Actually, I "liked" the book in the sense that it held my attention,
and I really liked Steve McConnell's book Code Complete. I also have
personal admiration for Steverino, who I met briefly.
spino...@my-deja.com
Why? Software engineering is not pure science and makes a partly
logical and partly rhetorical case for its methods. Its science
happens to be pretty good.
The problem is that the rhetoric seems to rely on acceptance of power
relations that are not guaranteed to produce success, and a fair
outcome for all stakeholders.
Part of the reasons organizations "buy in" to software engineering
methodology and then in a striking number of cases fail to realize the
promised savings, is precisely because the engineers haven't read
Foucault and Nietzche and do not view software engineering as BOTH
applied science and applied force.
Because they are simply unaware that they are on the receiving end of
power, rather than their traditional, comfortable and protected
position on the delivery end, they do not know how to pushback
appropriately when the methods are misapplied.
This results in an organizational cynicism in which it is pronounced
that the methods work, and that the diagrams and methodologies
correspond to the code, while the passive-aggressive engineers more or
less sullenly proceed to try to implement the system, with its
necessary aporias (gaps) resulting from the superficiality of the
design.
spino...@my-deja.com
js...@bluedog.apana.org.au (Jason Stokes) wrote:
> On Wed, 29 Nov 2000 18:05:21 GMT, Patrick Logan
<patric...@home.com>
> wrote:
>
> >"Jason Stokes" <js...@bluedog.apana.org.au> wrote in message
> >news:slrn929a1...@valis.local...
>
> Hmmm?
>
> I can't see why a software engineering book would want to address the
kinds
> of things he's talking about in his review, or have any relevance to
such
> issues. A programming book is about on the same level as a book on
> carpentry as far as social commentary is concerned.
That's the problem in a nutshell. The carpenter constructing a house
for a wealthy software engineer that his family cannot afford would be
well advised to preface his book on carpentry with reflections on the
justice of this situation. He'd also be well advised to work as hard
as possible to place on display, for future generations, that his
dignity survived a society in which homes are ever more lavish, yet
ever more unaffordable for vast segments of the population.
Even if we accept the ground rules of our society, which uses
inequality to motivate us to go to work, an intelligent manager would
do well NOT to naively present software engineering as just another
technology. He'd be sensitive to the feelings of his programmers, even
though he might, given the ground rules, proceed to downsize and in
general stick it to them anyway.
For it is very true that there are many programmers who THINK their
bricolage is the greatest thing since sliced bread, and who are quite
wrong. This truth happens to be logically consistent with the fact
that there are others (Andy Herztfeld of Apple comes to mind) who
indeed are world class geniuses but who nonetheless shafted by the
rhetoric of "structure" and "software engineering" anyway. In a 1986
interview, Andy relates how after developing the code for the
Macintosh, he nonetheless got a bad performance review that devil a
doubt used the management rhetoric of "structure" and "being a team
member."
Software engineering is excessively top down in that it "freezes" the
goals of the project even when the developers realize that these goals
need to be changed. Another Apple example is Hypercard: in the early
days of the Mac, it was difficult to develop even simple graphic
applications because they were an enormous hack in C or Basic. Bill
Atkinson wanted to make an end-run around this problem by developing a
sort of generalized graphical interface based on a "card" metaphor. He
had to work very hard on tasks set to him by Sculley until he received
the go-ahead as a "reward."
Actually solving a problem that underlay the problem as it was
management defined was treated by John Sculley as a trip to Cancun, a
reward, and a detour and frolic...when in fact Hypercard saved the
Mac. I fear that the software engineering approach, by its emphasis on
the "user" (ill-defined as only one stakeholder) and
his "requirements", does tend to prevent what used to be known within
IBM as pushback: bottom up critique and suggestions, including
Hypercard.
Please keep in mind that I am a software developer and not an English
teacher, although I have taught logic and critical thinking as well as
Visual Basic. I'm not bringing Foucault up to be pretentious, although
I can be quite pretentious when I want to be :-).
Jason Che-han Yip
news:903jdm$bqq$1...@nnrp1.deja.com...
> In article <slrn929a1...@valis.local>,
<snip>
> The problem is that the rhetoric seems to rely on acceptance of power
> relations that are not guaranteed to produce success, and a fair
> outcome for all stakeholders.
>
> Part of the reasons organizations "buy in" to software engineering
> methodology and then in a striking number of cases fail to realize the
> promised savings, is precisely because the engineers haven't read
> Foucault and Nietzche and do not view software engineering as BOTH
> applied science and applied force.
I have neither read Foucault or Nietzche so perhaps that's why I don't know
what you mean by applied force. I'm guessing that you're saying that
humanistic issues can and will cause approaches to fail.
Greg Menke
>
> Well, something has to freeze the goals of the project, if only to
> allow it to be completed. In my experience, it is usually the
> marketing department which does the goalpost moving function which you
> seem to require.
>
> What do you propose to fulfill the function of meeting the ever moving
> goal?
>
> In your scheme, how will projects be delivered as "completed"?
I think he's referring more to the slavish adherence to method over
substance; ie spending time in endless meetings talking about
"process" and "living documents" rather than digging into the real,
contradictory and ill-defined requirements a system must meet.
Getting the real requirements amounts to doing an old-fashioned
systems analysis on the existing system, learning what it does and
how, then identifying what the users need (in contrast to what the
users say they need). If the user cannot/will not define their goals
& requirements then you can't build a sucessful system no matter how
much time/money you spend. You may well build some things which do
work, but I imagine you'll end up in a never-ending development
process.
To be sure you have to shoot the analysts and start coding at some
point, but there is a difference between trying to avoid gratuitous
changes in requirements & spec and an arbitrary halt to all
consideration of change. The latter is a recipe for building a system
that doesn't meet user requirements even IF it actually gets
delivered. The former is how you adapt to a complicated and
incompletely understood problem- its imperfect, demanding, expensive
and not very predictable, but its what you have to do. You can either
have an expensive system you do once or a REALLY expensive one you
have to redo a quantity of times.
The trouble with many Software Engineering principles and
methodologies is they don't concentrate on doing the time-consuming,
difficult and error-prone process of getting the system requirements
straightened out- instead relying on "well defined procedures" which
are easy to specify, but don't help much when trying to understand
what a system needs to accomplish- or more importantly, coaxing a
non-technical project lead to devote his/her resources to spending
time with the users.
I've been developing systems of varying complexity since 1990 and have
yet to hear of a software engineering methodology which improves
significantly on the basic principle of studying what the user needs,
organizing it, adapting to change and implementing- usually in
combination. UML isn't much more than a notational change to the
entity/relationship/"flowcharting"/whatever we did a decade ago. The
CASE tools have marginally improved since, but not markedly. But
thats only my take on it... no doubt I'm part of the problem.
Frankly, I figure the SEI rating stuff has a half-life of about 4
years, its got 5 or 6 more before it falls into the dustbin of
antiquity. But, its in good company with TQM and all the other
philosophies which aren't dealing with the hard problems.
Gregm
spino...@my-deja.com
Foucault and Nietzche both showed how truth and power are linked and
are two sides of the same coin.
An example would be the plight of the "computer nerd" who makes a
presentation. People tend to mistrust him (his gender is typically
male) and dismiss his concerns as marginal to the "bottom line" or
the "main issues."
In ordinary biztalk it is said that the nerd needs to
learn "communications skills." While mechanical communications skills
such as how to make a presentation are of course valuable what is often
meant is not that the message was "communicated" poorly: it is a
failure to understand the message, or disagreement with its import.
And, following Foucault and Nietzche, we'd have to say that the
audience in the presentation inherits social attitudes. Computer nerds
have low status in American culture, therefore the audience tends to
discount what they have to say...whereas he who adopts the pose of
management gains truth through at least the appearance of power. Power
makes truth.
Patrick Logan
"Giles Todd" <g...@at-dot.org> wrote in message
news:4reb2tog59deslfpn...@4ax.com...
> On Wed, 29 Nov 2000 19:15:43 GMT, spino...@my-deja.com wrote:
>
> > Software engineering is excessively top down in that it "freezes" the
> > goals of the project even when the developers realize that these goals
> > need to be changed.
>
> allow it to be completed. In my experience, it is usually the
> marketing department which does the goalpost moving function which you
> seem to require.
>
> What do you propose to fulfill the function of meeting the ever moving
> goal?
>
> In your scheme, how will projects be delivered as "completed"?
The moving goal post is a reality that will not go away, ever. "Completed"
will
never be defined solely by the developer, having been handed a requirements
specification.
Software development has to come to terms with change *as* development
proceeds. (Top down is not the answer.)
Tom J
front. I think that DOD STD 2167A did so.
"Software Engineering" is a huge field big enough to include any
measured project management approach, including
measured iterative approaches.
Be careful of your examples of genius. I didn't buy an Apple, I bought an
Amiga. Now that's genius. Pre-emptive multitasking 12 or 13 years before
Apple on a $550 box.
--
Tom J.; tej at world.std.com Massachusetts USA; MSCS; Systems Programmer
Dist. Real-Time Data Acquisition S/W for Science and Eng. under POSIX,
C, C++, X, Motif, Graphics, Audio http://world.std.com/~tej
Al Dunbar
<spino...@my-deja.com> wrote in message
news:903ivs$bde$1...@nnrp1.deja.com...
> In article <t28vin8...@corp.supernews.com>,
> "Al Dunbar" <Al_D...@HoTMaiL.com> wrote:
> > Is it just me, or does this post somehow fail to give any real
> information
> > about the actual book it purports to review? Is the book as much about
> > "bricolage" as this article is?
>
> It's just you, Al. The review is not meant to be a "consumer guide",
> or ersatz for reading the book. For that, plenty of information is
> available on www.amazon.com and www.barnesandnoble.com.
I find it odd that you say that it is just me. The initial replies of Jason
Stokes and Patrick Logan seemed to me to be somewhat in agreement with my
comments. The fact that the thread has devolved into a discussion, however
valuable, that nonetheless has no bearing on the book also tends to support
my view.
I am well aware of the other sources of book review information that you
mention. Since I have never seen a negative review at a site that wants to
sell me a book, I generally find the newsgroups to provide more reliable
criticism. Just not in this case.
> The review is instead critique that airs views about "software
> engineering" that seldom see print.
It was fairly obvious that your post was, as you say, not a review of the
book but a critique that airs views that may or may not have had any
relationship whatsoever with the content of the book itself. Now, I am not
saying that I disagree with the content of your "review". Actually, I did
find it difficult to discern your actual views from your particular writing
style, which I think drew other comments as well. But that is neither here
nor there. Why did you call it a review of one specific book when it was in
fact an invective against what you disagree with about writers of such books
in general?
> Sorry you did not get value from the review, but if you do not share my
> disquiet about the ways in which some software engineers at one and the
> same time use and diss academic computer science, and programming
> bricolage, then the review wasn't meant for you.
I may indeed share your disquiet; I just have difficulty understanding what
you are getting at. Now, maybe that *is* just me.
/Al
spino...@my-deja.com
"Al Dunbar" <Al_D...@HoTMaiL.com> wrote:
>
> <spino...@my-deja.com> wrote in message
> news:903ivs$bde$1...@nnrp1.deja.com...
> > In article <t28vin8...@corp.supernews.com>,
> > "Al Dunbar" <Al_D...@HoTMaiL.com> wrote:
> > > Is it just me, or does this post somehow fail to give any real
> > information
> > > about the actual book it purports to review? Is the book as much
about
> > > "bricolage" as this article is?
> >
> > It's just you, Al. The review is not meant to be a "consumer
guide",
> > or ersatz for reading the book. For that, plenty of information is
> > available on www.amazon.com and www.barnesandnoble.com.
>
> I find it odd that you say that it is just me. The initial replies of
Jason
> Stokes and Patrick Logan seemed to me to be somewhat in agreement
with my
> comments. The fact that the thread has devolved into a discussion,
however
> valuable, that nonetheless has no bearing on the book also tends to
support
> my view.
>
who share your assumptions and your world-view.
Look, mate, I am well aware that MOST developers in our culture would
feel that my concerns are not relevant to software engineering is in my
view part of the problem set. I am well aware that the very idea that
literature, or Foucault, has any relevance to software engineering is
strange, indeed offensive to developers who believe that software
engineering is Science.
I am trying to explain the vague unease that many of these developers
nonetheless feel at the fact that parts of software engineering seem
more concerned with dominance and control than with Science. I am
trying to account for the programmers who left early structured
walkthroughs in tears because their world view turned out to be
inconsistent with the realities of capillary power.
> I am well aware of the other sources of book review information that
you
> mention. Since I have never seen a negative review at a site that
wants to
> sell me a book, I generally find the newsgroups to provide more
reliable
> criticism. Just not in this case.
>
Amazon posts negative reviews. It's posted my review of Steve
McConnell as of today. For positive and negative customer reviews
check Customer Comments. You are sure to find people who share your
concerns rather than mine, and who give unbiased information.
> > The review is instead critique that airs views about "software
> > engineering" that seldom see print.
>
> It was fairly obvious that your post was, as you say, not a review of
the
> book but a critique that airs views that may or may not have had any
> relationship whatsoever with the content of the book itself. Now, I
am not
> saying that I disagree with the content of your "review". Actually, I
did
> find it difficult to discern your actual views from your particular
writing
> style, which I think drew other comments as well. But that is neither
here
> nor there. Why did you call it a review of one specific book when it
was in
> fact an invective against what you disagree with about writers of
such books
> in general?
>
Again: issues of writing style are part of the problem set. Some
software engineering, in an honest attempt to visualize complexity,
oversimplifies complexity that ultimately can only be expressed by a
text. For example, many developers of database systems place, on the
walls of their cubicles, elegant maps of the key relationships of
whatever data base they have been developing and managers and many
developers believe that this artwork shows that the project is under
control.
The problem is that as most database systems evolve over time, these
charts, difficult to produce even using excellent tools such as Visio,
become perniciously out of date. The devil is in the details, for
their express purpose of serving as an encyclopediac quick reference
simply is not met in critical cases.
This is overall a freeze-frame approach to technical reality...which is
influenced not so much by scientific or technical considerations as by
our culture, which is ahistorical and present-oriented. For the same
CULTURAL reason developers flock to blockbuster movies with freeze-
frame "happy endings" they seek to freeze software in visuals despite
the known fact that requirements change.
The reality is that of the program text (as Derrida said, there is
nothing but the text.) This is partly to say, like the old-fashioned
programmer, that the code is the documentation and as such it will be
an unattractive conclusion both to me, and to the software engineers
and architects. But an Open Source approach to code can make this
reality far more transparent than it is. Most business systems that
affect our lives are protected by a wall of documents, made with the
best of intentions, that simply are not known to correspond to the
working code.
However, this has a result that will be frightening to American
business. To use Open Source for critical business systems is to open
your books to public oversight and control.
Most CEOs are honest according to current standards, and they don't
want their accounting software to violate generally accepted accounting
systems, and businesses no longer run their own payroll in order to
ensure their employees aren't screwed by private payroll software.
Nonetheless, there is a competitive advantage in running software that
accidentally or purposely ignores laws the business does not like.
Plausible deniability (where the CEO, and even the CIO does not KNOW
that the software is systematically and unfairly giving them an
advantage) kicks in, and the corporation enjoys advantages in closed
source that would be lost in open source. For example, IBM for years
monkeyed with its pension software for years, making almost
incomprehensible changes that systematically screwed its retirees.
This message takes as many words as it takes. Part of the problem set
is the brutalization of writing style found in design documents where
simplification for its own sake is accounted a virtue.
As to "invective." Because software engineering is as much about power
as it is about truth, it has treated critique not thoughtfully but with
a certain amount of brutality. For example, computer scientist Edsger
Dijkstra gained a reputation in the 1970s as a bad boy for defining
software engineering as "programming, for people who can't program."
There are all sorts of programmers, and some of them have risen from
the working class and themselves worked very hard to learn their
trade. Software engineering tends to diss them in a uniform way as
trolls. Of course, for the last 40 years, the trolls have had the
last laff in the job market, for like Kipling's British soldier:
It's Tommy this, and Tommy that, and Tommy, go away
But it's "the savior of his country" when the band begin to play
That is, when the manager needs someone who can cut code, when the band
begins to play, he doesn't hire a software architect, no matter what
certificates the architect may provide.
> > Sorry you did not get value from the review, but if you do not
share my
> > disquiet about the ways in which some software engineers at one and
the
> > same time use and diss academic computer science, and programming
> > bricolage, then the review wasn't meant for you.
>
> I may indeed share your disquiet; I just have difficulty
understanding what
> you are getting at. Now, maybe that *is* just me.
My disquiet commenced in Silicon Valley in the early 1980s and I
started reading French theory and Frankfurt School critique, along with
technical books, at that time. I was troubled by the promise of
liberation implicit in the early days of the microcomputer and the way
it morphed before my very eyes into real servitude: for example, I went
straight from having to wear as suit and tie to being forbidden to wear
a suit and tie without getting to visit that land where I could dress
as I goddamn well pleased. Foucault speaks directly to the ways in
which power uses apparent pleasure (such as business casual) to attain
ends that may be at variance with human needs.
Ultimately, correct software is a philosophical problem because the
very idea of correctness disappears in virtual reality. Note that in a
computer game, the program does not have to be correct since the world
is the world of the game. Our inability to write correct software may
be due to the fact that increasing computerization and the
virtualization of reality steadily reduces our epistemological
confidence in being able to describe reality, outside of code. By
saying shocking things like "there is nothing but the text", French
theory at least points out the ways in which we're losing our grip.
This is better than happily writing "mindless code" which we never test
against reality, history, common sense, and morality.
Jay
I read the book and its a no brainer that software engineers
need to organize. This is obvious for the following reasons:
(1) Drive up the requirements for software engineers to depress the
number of SEs and increase the status of software engineering,
thus driving up wages, prestige and programmers desirability by hot
chicks.
(2) Drive up the requirements for software engineers so that we don't
have to work with annoying Bozos.
(3) Stop the flooding of the marketplace with cheap labor.
(4) To increase our power over management so that we can create quality
systems, i.e. throw our weight around to stop management Dilbert-like bumbling.
(5) To increase our power over management so that we can jerk their chains
because they are a bunch arrogant assholes.
(6) Increase power over marketing/monopolization forces that make the field
(like M$ tools) so arbitrary and braindead.
etc.
Jay
spino...@my-deja.com wrote:
>
> In article <t2cuv33...@corp.supernews.com>,
Don Chiasson
spino...@my-deja.com wrote
>............ developers who believe that software
>engineering is Science.
The strength of science lies in the fact that there are
generalizations. Software is engineering in that there
are not generalizations, only improved algorithms
or techniques.
> .......developers
> nonetheless feel at the fact that parts of software
> engineering seem more concerned with dominance
> and control than with Science. I am
> trying to account for the programmers who left
> early structured walkthroughs in tears because their
> world view turned out to be
> inconsistent with the realities of capillary power.
>
The exercise of power in working environment is a reality.
In certain cases, it is a necessity. In far too many others,
it is an ego trip for a manager. It is not unique to
software engineering.
I do not understand the word "capillary." The common
usage is a "minute blood vessel" (Encarta) or "of or like a
hair (of tube, blood vessel, etc.)" (Oxford Dictionary of
Current English).
There is also an equating of truth and power (sorry I
clipped the exact phrase). Life may often exhibit this
characteristic. But, truth can exist independent of power.
It is, unfortunately, also true that power can exist
independent
of truth. (Yes, grammatically I am wrong: I don't like the
way
the word "independently" scans.)
Don
Pete Fenelon
> I think he's referring more to the slavish adherence to method over
> substance;
Which reminds me of a CV I reviewed recently for a guy applying
for a software engineering position in the pretty heavily R&D-driven
company I work for... the poor soul actually boasted of his his
ability and willingness to work in an environment completely governed
by inflexible rules. Needless to say, I didn't choose to call him
for interview. I don't think he would've understood me....
pete
spino...@my-deja.com
Aww, man, I wanted to maintain a high class tone.
>
> I read the book and its a no brainer that software engineers
> need to organize. This is obvious for the following reasons:
>
> (1) Drive up the requirements for software engineers to depress the
> number of SEs and increase the status of software engineering,
> thus driving up wages, prestige and programmers desirability by hot
> chicks.
Yeah, baby!!
But note your low class phraseology is part of the problem set whereas
my high class "philosophical" phraseology is part of the solution set.
First of all, high class phraseology and a philosophical tone has
always been a chick magnet.
Secondly, elites image subordinate classes as motivated by appetite
whereas they, of course, are motivated by pure ideals. This nonsense
was started when Socrates got drunk and started kidding around (cf. The
Republic.) People took his imaginary tale of a disinterested elite, as
contrasted with us bums (motivated as we are by our libido) as the
truth, with the result that George Dubya is a disinterested Guardian of
our interests.
Of course, Woodstock 1999 did show that actually existent slobs are
indeed unqualified to lead themselves, but this may be an artifact of
their subordination to elites, curable after a series of Outward Bound
expeditions. Malcolm X showed us that there is no social change
without personal change. Seattle 1999 showed that people can act right
while diverging from the dominant paradigm. Woodstock 99 was the last
gasp of the silly hippie idea that redemption starts with personal
gratification, and it showed the point at which Foucauldian control
through pleasure fails.
More seriously, consider imagining hot chick scarcity as a social
injustice. That is, software engineers, being for the most part guys,
have guy ways of narrating their lives. Different ways of narrating
our lives may be called for.
If on a Friday night, after a week of 16 hour days essentially fixing
Microsoft's bugs, with the boss blaming us for taking too long and no
time to even ask that hot number out, all we have is The Man Show and
CNN, the fact that we narrate our lives using dominant discourse makes
us feel like losers.
Suppose we started with the demand for emotional justice. Emotional
justice is not a song by the Rolling Stones (that's Emotional Rescue,
see, I'm hip, chukka chukka.) Emotional justice is the unimagined
reverse of the hegemomic situation which we take as a given in the
1990s.
In the hegemonic situation, Americans endure levels of isolation that
shock and disturb visitors from other countries.
Therefore, if we changed the "I'm a loser" narrative to "it is not just
that I do not have a community, in which I might get to talk to people
of the opposite sex without the threat/fear of violence which is used
to separate us" our narrative is less manly but perhaps more useful.
That is, guys narrate themselves as horny when in fact they are lonely.
>
> (2) Drive up the requirements for software engineers so that we don't
> have to work with annoying Bozos.
>
Sounds good.
> (3) Stop the flooding of the marketplace with cheap labor.
>
I support this, except I don't support racist and unworkable labor
protectionism. I support a fair and just free market in capital and
labor worldwide with high levels of unionization.
> (4) To increase our power over management so that we can create
quality
> systems, i.e. throw our weight around to stop management Dilbert-like
bumbling.
>
Yeah baby!!
> (5) To increase our power over management so that we can jerk their
chains
> because they are a bunch arrogant assholes.
>
Sounds great, less filling.
> (6) Increase power over marketing/monopolization forces that make the
field
> (like M$ tools) so arbitrary and braindead.
>
People are preparing for Visual Basic 7 as if it is Godzilla or King
Kong.
> etc.
>
> Jay
>
> spino...@my-deja.com wrote:
> >
> > In article <t2cuv33...@corp.supernews.com>,
>
spino...@my-deja.com
"Don Chiasson" <don_ch...@hotmail.com> wrote:
>
> spino...@my-deja.com wrote
>
> >............ developers who believe that software
> >engineering is Science.
>
> The strength of science lies in the fact that there are
> generalizations. Software is engineering in that there
> are not generalizations, only improved algorithms
> or techniques.
I'm not sure this is true. "Go to considered harmful" (letter,
Communications of the ACM, Aug 1968, Edsger Dijkstra) was a
generalization.
>
> > .......developers
> > nonetheless feel at the fact that parts of software
> > engineering seem more concerned with dominance
> > and control than with Science. I am
> > trying to account for the programmers who left
> > early structured walkthroughs in tears because their
> > world view turned out to be
> > inconsistent with the realities of capillary power.
> >
>
> The exercise of power in working environment is a reality.
> In certain cases, it is a necessity. In far too many others,
> it is an ego trip for a manager. It is not unique to
> software engineering.
Absolutely. Software engineering in America shares cultural
understandings with other engineering disciplines.
In American engineering culture in general, the boss has absolute power
over technical decisions when he chooses to exercise that power and
extensive discussion after the decision has been announced is regarded
often as backtalk. As in Leninist "democratic centralism", discussion
is welcomed before the management decision but not after.
It would of course be impossible to run a shop if decisions could be
vetoed in practice for then they would not be decisions. However,
there are successful software departments where people use voting or
the opinions of the team. But because of time pressures and a cultural
understanding (that the 1960s were a mistake, and no more) these shops
are on the wane.
It does appear that in certain cases, foreign software creators are
more successful than Americans owing to different cultural
understanding. Two examples come to mind.
The data base product SAP has been an enormous success because it
essentially seems to have violated the American cultural
commandment "don't reinvent the wheel", for SAP uses a proprietary
interface, essentially a data base, to protect it against changes in
commercial data bases...notably SQL Server. My belief is that SAP,
which was fabricated in Germany, was created this way because "don't
reinvent the wheel" is used in America to discipline ambitious
engineers who have decided that the wheel, like the tires on Ford SUVs,
is broken.
Another example is a clone of Microsoft Office, called Wordstar. When
many programmers learn about Wordstar they feel it is not legal, but as
it happens, it is.
The cultural background for their solicitude for an imagined property
right in the externals of Microsoft Office goes deep. American
engineering culture inherits legal decisions of the 19th century which
made private property NOT ONLY an important right (following Locke) BUT
ALSO the only meaningful right. In the 1850s, the black man was (in
the abominable words of Chief Justice Roger Taney in *Dred Scott*) a
man whose rights no white man need respect. By 1900, this was the man
without property, for in several decisions, the courts found that
private property was the ONLY thing that conferred full humanity.
For example, a manufacturer of flax (a highly inflammable substance)
was allowed in this period to stock it close to a railroad track
despite the fact that excess flax regularly set the wooden steam trains
on fire, a fact which made the railroad men rather sad. It appears
that the Supreme Court of the late 1900s found this a hard case because
no rights (such as the right to be safe from burning flax) could be
based on anything other than ownership.
This, and countless other practices inherited from the 19th century,
influences our thinking: we assume that Microsoft owns the overall
behavior of Office, when in fact Wordstar used its published
documentation to make a somewhat equivalent product.
"Don't reinvent the wheel" is based on the precept of laissez-faire
economics, "the law of comparative advantage." But as a society,
Germany has always been more protective than 20th century America of
its own technology and less willing to use innovations from abroad.
This is because of the greater cultural prestige of German engineers.
A disturbing sidelight is that this German cultural tendency reached
its zenith under Adolf Hitler: in his mad paradise, engineers had a
great deal of power and control, and since the Krauts went to war with
the entire world as soon as possible, they had to reinvent the wheel
along with rubber. I mention this to forestall the usual Internet
tendency to compare views at odds with hegemony to those of Hitler, for
there are modern, non-Fascist societies with greater respect for labor
and engineering.
>
> I do not understand the word "capillary." The common
> usage is a "minute blood vessel" (Encarta) or "of or like a
> hair (of tube, blood vessel, etc.)" (Oxford Dictionary of
> Current English).
>
> There is also an equating of truth and power (sorry I
> clipped the exact phrase). Life may often exhibit this
> characteristic. But, truth can exist independent of power.
> It is, unfortunately, also true that power can exist
> independent
> of truth. (Yes, grammatically I am wrong: I don't like the
> way
> the word "independently" scans.)
My interpretation of Nietzche is that in mediaeval terms he was a
strong nominalist, and believed that truth and power were two names for
the same thing. African philosophy teaches us that many African
peoples were more interested in life-force than in truths that do not
make us whole, and the Buddha lectured his monks on truths that "tend
not to profit."
Perhaps power is what gives us the truth and truth, power. Perhaps
information is less a commodity than a giving up of power, and perhaps
it is being privatized as a way of over-centralizing power.
>
> Don
Jay
> If on a Friday night, after a week of 16 hour days essentially fixing
> Microsoft's bugs, with the boss blaming us for taking too long and no
> time to even ask that hot number out, all we have is The Man Show and
> CNN, the fact that we narrate our lives using dominant discourse makes
> us feel like losers.
No Way! Bzzzt! Can't happen! With Steve McConnell's vision of our
newly professionalized software engineering field, we will have
software processes and our bosses under control and thus we will
be out by 5PM everyday to which we will hop in our sports
car to go pick the designated hot young babe for that day of the week
(we are talking weekdays here!). Our newly acquired software engineer
desirability would of course requiring special time
scheduling software to keep track of all those dates with the women!
> Therefore, if we changed the "I'm a loser" narrative to "it is not just
> that I do not have a community, in which I might get to talk to people
> of the opposite sex without the threat/fear of violence which is used
> to separate us" our narrative is less manly but perhaps more useful.
> That is, guys narrate themselves as horny when in fact they are lonely.
More seriously. If software was not such a stupid isolating brain dead
rat race, the field would be more desirable and thus attract more women.
A more 50-50 split between women and men in software would of
course benefit the social aspects of the field greatly (and
thus further increase the desirability and prestige of the field)
Jay
Al Dunbar
<spino...@my-deja.com> wrote in message
news:906d86$lec$1...@nnrp1.deja.com...> > <snip - because we have seen it enough times already>
> > I find it odd that you say that it is just me. The initial replies of
> Jason
> > Stokes and Patrick Logan seemed to me to be somewhat in agreement
> with my
> > comments. The fact that the thread has devolved into a discussion,
> however
> > valuable, that nonetheless has no bearing on the book also tends to
> support
> > my view.
> >
> That's great Al. But it's just you, and thousands of other developers
> who share your assumptions and your world-view.
It is ludicrous that you think you have any concept of either my assumptions
or my world-view when my ONLY comment has been that what you labeled as a
review is anything but. Perhaps you spend so much time writing that you have
little time to read the responses, such as the one where I said "I may
indeed share your disquiet; I just have difficulty understanding what you
are getting at."
> > <snip - because we have seen it enough times already>
Al Dunbar
<spino...@my-deja.com> wrote in message
news:90745i$8vk$1...@nnrp1.deja.com...
> In article <3A26C6AB...@jay.jay.org>,
> Jay <j...@jay.jay.org> wrote:
> > That review is way to "philosophical" for its own good.
>
> Aww, man, I wanted to maintain a high class tone.
Style without substance. I sort of thought that would be something you would
be against, but then, perhaps I still misunderstand you.
> >
> > I read the book and its a no brainer that software engineers
> > need to organize. This is obvious for the following reasons:
> >
> > (1) Drive up the requirements for software engineers to depress the
> > number of SEs and increase the status of software engineering,
> > thus driving up wages, prestige and programmers desirability by hot
> > chicks.
>
> Yeah, baby!!
>
> But note your low class phraseology is part of the problem set whereas
> my high class "philosophical" phraseology is part of the solution set.
Odd, I haven't seen this solution implemented anywhere.
> First of all, high class phraseology and a philosophical tone has
> always been a chick magnet.
OK, OK, I think I finally get what's going on here, people. We are being had
by a Turing experiment gone slightly off its rails. An admirable try on the
output side, but somewhat weak on the input.
<snip - we have already seen enough of this>
Eric Fischer
> Another example is a clone of Microsoft Office, called Wordstar.
WordStar, the classic CP/M word processor of the late 1970s, has
become a clone of Microsoft Office? Is nothing sacred?
(Tangentially related: does anyone know whether the company now
selling CD-ROM drives under the Digital Research name has anything
to do with the Digital Research that was responsible for CP/M?)
eric
Jay Maynard
>become a clone of Microsoft Office? Is nothing sacred?
I'd avoided spinoza9999's multi-hundred-line socialist rants after getting
a few lines into the first few and bouncing off the impenetrable rhetoric a
while back...all with a vague feeling that I was mainly bypassing a traincar
load of male bovine exhaust. Thank you for picking out this little gem and
confirming that.
Free clue: WordStar preceded M$ Word by a decade.
Al Dunbar
"Jay Maynard" <jmay...@thebrain.conmicro.cx> wrote in message
news:ACBDCDA1677757BC.63EFF2E3...@lp.airnews.net...
> >become a clone of Microsoft Office? Is nothing sacred?
>
> I'd avoided spinoza9999's multi-hundred-line socialist rants after getting
> a few lines into the first few and bouncing off the impenetrable rhetoric
a
> while back...all with a vague feeling that I was mainly bypassing a
traincar
> load of male bovine exhaust. Thank you for picking out this little gem and
> confirming that.
So, perhaps it's NOT just me! :-)
/Al
Eric Smith
> My point was that there must come a stage where discussion stops and
> focussed activity starts.
Amen, brother! Let's form a planning committee to develop a list of
action items.
spino...@my-deja.com
<ACBDCDA1677757BC.63EFF2E3...@lp.airnews.net>,
jmay...@conmicro.cx wrote:
> On 1 Dec 2000 18:43:04 GMT, Eric Fischer <e...@pobox.com> wrote:
> ><spino...@my-deja.com> wrote:
> >become a clone of Microsoft Office? Is nothing sacred?
>
> I'd avoided spinoza9999's multi-hundred-line socialist rants after
getting
> a few lines into the first few and bouncing off the impenetrable
rhetoric a
> while back...all with a vague feeling that I was mainly bypassing a
traincar
> load of male bovine exhaust. Thank you for picking out this little
gem and
> confirming that.
Sorry for the typo. The product name is StarOffice. It's likely you
are ignorant of the product.
Furthermore: if the style of the original post was offputting it is
then not intended for you. As I have indicated, hatred of what is
misnamed wordiness can be hatred of language itself, and the desire of
some software engineers to free themselves of the tests of history,
language, morality and common sense.
spino...@my-deja.com
Jay <j...@jay.jay.org> wrote:>
> More seriously. If software was not such a stupid isolating brain dead
> rat race, the field would be more desirable and thus attract more
women.
> A more 50-50 split between women and men in software would of
> course benefit the social aspects of the field greatly (and
> thus further increase the desirability and prestige of the field)
>
> Jay
In many ways, the presence of women professionals in the field raises
the tone. Steve book has an example: the NASA group he describes is
more equitable than the normal group.
This group uses modern software engineering practises and people
typically leave work at a reasonable hour (Steve makes what I think is
a major error here: he ascribes the reasonableness of the hour to the
practices: it's probably the fact that these are government employees
not as subject to death-march schedules, and NASA, post-Challenger, is
wary of death-march schedules.)
Women tend not to want to work the animalistic work hours that male
software engineers work, and this is a virtue.
However, they introduce strains of their own. Deborah Tannen is a
researcher on gender-differentiated styles of computer use, and she's
shown that the virtue and vice of male technicians is their willingness
to push the envelope and take risk, whereas on the whole the virtue and
vice of women engineers is their willingness to slow down and go by the
book. Women are sometimes just afraid of programmers actually
programming, and in my view they are a major force in downsizing and
deskilling as they discourage their programmers from programming.
Women also remind us of the fact that when the modern fully respected
professions of medicine and law were formed in the USA, the formation
was an occasion of extreme sex discrimination. Part of the reason
doctors organized into the modern medical profession was quite
consciously to eliminate the profession of midwife and the women who
assisted in abortions. Even in the early 1960s, women were rare in law
schools, and had to put up with a great deal of hijinx when they did
attend.
This sort of sex discrimination could be institutionalized if
programming became a profession on Steve's model.
Already, Microsoft testing is primarily informed by adolescent male
competitive values for it's whole theme is "you think you so smart."
Many of its questions constitute what I regard (as an adjunct faculty
member) as educational malpractice. I was saddened and astonished,
even though I'm Microsoft certified, to see a woman coworker fail a
Microsoft test repeatedly although she had an advanced degree from a
European university.
Tests in general are biased towards students of higher social class,
and Microsoft tests are biased towards the sort of guy who likes
solving puzzles rather than real problems. They also overemphasize
using Microsoft solutions that at times are inferior to third-party
solutions and so-called "reinventing the wheel."
The extraordinarily poor design of Microsoft tests led, a few years
ago, to cynical gamesmanship in which "boot camps" (another male
metaphor) taught completely unqualified people the answers by rote, and
there has been considerable dishonesty within corporations that require
Microsoft test-takers to "teach" others...by giving them the questions
and the correct answers.
Steve's book is simply uninformed of the cultural and historical matrix
in which the modern full professions of law, medicine and traditional
engineering took place. Although they were formed in the sexism and
racism of the late 19th century, they matured during a liberal phase of
American history which actually encouraged people to better themselves
by becoming professionals, and which reluctantly but steadily welcomed
women and nonwhites into the ranks of professionals.
Our time is considerably different. To be gracious about entry into an
upper middle class profession, whether one's own entry or another's, is
taken as a sign of weakness, for due to the very collapse of tradition,
we're all fighting for the same diminishing pie.
The very opening of the legal profession, while necessary and just, led
in our society to unprecedented levels of despair among actual lawyers
as they no longer were made to feel as if they were "special". They
instead discovered that becoming an associate in a law firm involved
just another paper chase to make partner (as adjunct faculty yearn for
tenure) and they discovered that their work, similar to much work in
data processing, was so much under the control of mega firms and their
mega mega clients that it had no meaning.
The result is that when people talk about professional issues in many
fields including computing, their talk is less about ideals and more
about who gets what. "I'm a doctor and you're not", "I'm a lawyer and
you're not", and "I'm a software engineer and you're not" are slogans,
the form of which appeared in the 1970s as people realized that
traditional forms of distinction were on the wane, but was not (thanks
to the economy) about to replaced by a paradise of equality.
In Minnesota poet Robert Bly's vision of the "sibling society",
the "grownups", those who are professionals or who seek to
professionalize, unconsciously become children chanting "I'm a software
engineer and you're not", or "ha ha ha, you flunked your Microsoft
exam." In Bly's view they do so precisely because their elder siblings
have abandoned history and culture (as Steve unconsciously does, by
reducing software engineering to technology) and placed themselves, and
everybody else, into an insane struggle for place and position.
This nasty brew is not a good place to start testing programmers for
legal certification. A better solution would be to let the free market
decide who's a software engineer, and for the software engineers to
organize, not professional societies, but trade unions. Instead of
reducing programmers to tears with poorly designed examinations or
structured walkovers, the union hall would teach and mentor
programmers, and help them find jobs. Through solidarity, it would be
a place of healing, as well as a great place to meet hot chicks :-).
spino...@my-deja.com
"Al Dunbar" <Al_D...@HoTMaiL.com> wrote:
>
> <spino...@my-deja.com> wrote in message
> news:90745i$8vk$1...@nnrp1.deja.com...
> > In article <3A26C6AB...@jay.jay.org>,
> > Jay <j...@jay.jay.org> wrote:
> > > That review is way to "philosophical" for its own good.
> >
> > Aww, man, I wanted to maintain a high class tone.
>
> Style without substance. I sort of thought that would be something
you would
> be against, but then, perhaps I still misunderstand you.
>
> > >
> > > I read the book and its a no brainer that software engineers
> > > need to organize. This is obvious for the following reasons:
> > >
> > > (1) Drive up the requirements for software engineers to depress
the
> > > number of SEs and increase the status of software engineering,
> > > thus driving up wages, prestige and programmers desirability by
hot
> > > chicks.
> >
> > Yeah, baby!!
> >
> > But note your low class phraseology is part of the problem set
whereas
> > my high class "philosophical" phraseology is part of the solution
set.
>
> Odd, I haven't seen this solution implemented anywhere.
Norwegian computer consultant Tom Gilb authored some excellent books on
software engineering and humanized input in the 1970s. He's also
written about what he calls the "Scandinavian critical model" of
computer science, which gives a greater level of respect and visibility
to data processing labor.
Gilb's theories about "humanized input" became the ergonomics of the
1990s and indirectly influenced the design of the Macintosh. They seem
to derive from the culture of Scandinavian societies, in which the
keypunch operator of the 1970s was not invisible or a form of lowlife
but a person, a citizen, demanding recognition and respect ON THE
JOB...in the form of data processing systems that (instead of
monitoring her for "productivity") used the computer to supply
reasonable and labor saving defaults, and to error check in a labor
saving rather than hostile way.
Here in the States, even today, many companies use keystrokes per
minute as a measure of "productivity": this measure takes as a given
that the keystrokes are the mininum necessary, and, in the States, this
is considered to be a closed question, answered by management once and
for all.
Gilb's work also made visible (as did the contemporary structured
programming revolution) the need of the programmer for some sense of
comprehension and mastery. When structured programming began it was
invented by programmers to save themselves time and to attain some
needed control over their work lives: but because in our culture the
worker is supposed (when push comes to shove) to abandon this in favor
of income, structured programming was gradually taken over by
management.
But Gilb, in his more modern work, has preserved a moderately pro-
labor, critical stance. In a recent article, he has clearly enough
stated that computing snafus are almost never the fault of incompetent
and/or lazy programmers, but of poor management decisions.
"Critical data processing" has been all over the world a source of
quiet success stories. Now, it is true that the people who take a
humanistic, compassionate, and moderately pro-labor stance in their
work don't read Foucault, and lack my taste for going on and on like I
do. The problem is that they cannot form a coherent intellectual
defense, even in their internal monologues, when their successful,
compassionate work-group is taken over by Sharks Is Us, Inc. They are
thus voiceless (even in their internal monologue) when dragooned into
such marvelous Bad Ideas such as Rigid Limits on Software Design (a
real methodology which admits of NO changes to deadlines) or Peoplesoft.
I am somewhat arrogantly trying to give a name and form to what I have
seen as success in software development and universally it seems to me
that software is most successful when it is critical, human, pro-labor,
compassionate. Of course, I do not mean financial success,
necessarily. I mean instead a holistic success in which NO
stakeholder, including the programmers, pay for the success with
exhaustion, broken marriages, and other tragedies.
>
> > First of all, high class phraseology and a philosophical tone has
> > always been a chick magnet.
>
> OK, OK, I think I finally get what's going on here, people. We are
being had
> by a Turing experiment gone slightly off its rails. An admirable try
on the
> output side, but somewhat weak on the input.
>
Sorry you feel that way. I am not a Turing experiment although I am
almost as weird as Turing was.
> <snip - we have already seen enough of this>
>
>