Forum on Risks to the Public in Computers and Related Systems
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Volume 11: Issue 90
Thursday 13 June 1991
Contents
Re: Formal-dehyde and Exper-topinion- PGN
- Re: Formalism versus Experimentation
- Nancy Leveson
Paula M. Ferguson
Mary Shafer
Leslie DeGroff
Mart L. Molle
Rick Smith
Michael L Muth
Brinton Cooper
Ed Nilges
Glen Ditchfield - Info on RISKS (comp.risks)
Formal-dehyde and Exper-topinion
"Peter G. Neumann" <neumann@csl.sri.com>
Thu, 13 Jun 91 13:43:30 PDT
OK, gang, it seemed to be a reasonable bet that Ed Nilges' message in RISKS-11.86 would start a lively discussion. But it was rather less constructive than I had hoped, and many of you missed the bigger picture. Well, now we are starting to run off into all sorts of tangential directions. Thus, I hope that this issue and some other contributions that must be deferred to RISKS-11.91 because I try to hold issues smaller than the 32Kbytes (which is the limit for some of your mail systems) will be last of it for a while -- unless something incisive comes in from Edsger Dijkstra or Karen Frankel or Danielle Bernstein... And if you feel you must reply to this issue, please wait until you see RISKS-11.91, with a few more items on this subject. But let's stick to the basic issues, not to second- and third- and even fourth-order incrementals. Those tend to get tiresome quickly for most readers, and your moderator runs the risk of swinging from more-inclusive mode to more-exclusive mode... Thanks. P.
Re: Formalism versus Experimentation
Nancy Leveson <nancy@murphy.ICS.UCI.EDU>
Thu, 13 Jun 91 10:09:40 -0700
For some reason that I don't understand, an early draft of my message to Risks was sent instead of the one I spent two hours polishing (sigh). You'll have to take my word that it was great :-). Here is the final paragraph that was totally missing in the version printed: I am most appalled at the implication in many of the messages that have appeared in Risks that in order to get more women into computer science, standards must be lowered. That is, they imply that the main reason why women are not participating is because they are not capable of logical and mathematical thinking and getting more women means that worse (and riskier) software will be produced. The reason for the low number of women in our field stems more from this type of prejudice than from any lesser ability. I have written about the extra barriers and difficulty that women face in becoming computer scientists. If you are interested, an article that appeared in the Newsletter of the Computing Research Association can be obtained via anonymous ftp from ics.uci.edu -- the article is in pub/nancy/snowbird (print using troff -ms). In this same directory, by the way, you will find a long (but incomplete) list of women PhD.s in Computer Science or Computer Engineering who are professors in Ph.D.-granting universities or in industrial research.
Women and computer science education
Paula M. Ferguson <paula@lta.lta.com>
Thu, 13 Jun 1991 14:16:04 -0400
I find it telling that all of the dialogue on this subject has been between
men. Maybe that speaks to the fact that there aren't very many of us women
in the field of computer science.
[Don't forget Nancy Leveson's item in RISKS-11.88!]
I have some strong ideas about this subject, having spent my senior year
writing a thesis about issues of women and computer science education. Before
you decide to dismiss my position as the ranting of a feminist, let me tell you
a little bit about my background. I graduated last year from MIT with a B.S in
computer science, so I'm not talking about this issue on an abstract level, but
rather from personal experience as a woman in a computer science program. I
did quite well in my "formal" programming courses and I am now working for a
small software development company.
I think that it is fairly obvious that there is something about computer
science that discourages women from entering the field. One place to look for
discouraging forces is in the realm of computer science education. While the
percentage of women at MIT is around 35%, the percentage of women in computer
science is 22%. What is more interesting is that the enrollment of women in
the introductory computer science course is around 30%. This class is the
first class that someone who is thinking of majoring in computer science would
take. Is there something that about the course that causes women to decide not
to major in computer science? I think so. This topic was the subject of my
thesis, but I'm not going to go into it here, except to say that it has a lot
to do with the course's emphasis on abstract, logical reasoning. I was a lab
assistant for the course for two years, so my conclusions are based on
extensive observation of students taking the course.
I am not advocating the elimination of training in formal logic from the
computer science curriculum. I think that computer scientists need a
background in this area. Structured programming is necessary for large
programming projects, to manage complexity, reduce the potential for errors,
and help in all of the other ways that it does. However, I don't think that
training in formal mathematics and logic should be the only training for
computer scientists. It also should not be the first subject in a computer
science program. The field of computer science is much more than just
structured programming. There is room for a lot more creativity than is
allowed by formal logic. After taking the introductory computer science course
at MIT, I decided not to major in computer science because I didn't enjoy
formal programming. I thought that structured programming was all that people
with computer science degrees did. After a year and a half of electrical
engineering courses, I changed my major to computer science and discovered that
there is a lot more to the field than I originally thought.
One problem with the almost universal focus on logic and abstract reasoning in
computer science education is that it affects all levels of computer education.
Programming courses in high school demand that students use structured methods.
Even courses in Logo for grade school kids emphasize procedures and
abstraction. It hardly seems necessary to start training kids how to write
"correct" programs at that age. One of the reasons that there are so few women
in college computer science programs is not that they are turned off to
computers in college, but that they are turned off to computers at a much
earlier age.
There is a lot of evidence from psychology and sociology that supports the idea
that women and men have different cognitive styles. Our society and its
educational system values abstract, logical thinking, which is typically the
male domain. Women's styles of thinking are seen as inferior. I haven't read
Frankel's article in CACM so I don't know if Ed Nilges' paraphrasing is
accurate:
> mathematics on logic.) Nye, and apparently Bernstein, believe that solitary
> abstract thinking is a typically male activity and to force women to engage in
> it is sexist.
Forcing women to think abstractly isn't sexist. If Bernstein calls it sexist,
it is unfortunate. However, setting up a system that values the male style of
thinking and devalues the female style is sexist. These values create a
roadblock that women have to overcome to succeed in the male-defined and
dominated world of computer science. Faced with these barriers, all but the
most determined women will give up at some point, either in grade school, in
college, or at the professional level.
There is little room for creativity in a world that is ruled by formal logic.
A number of areas of computer science have have benefitted greatly from
creativity that probably never would have happened within the constraints of
abstract thinking. Two areas that come to mind are artificial intelligence and
user-interface design. The argument, raised by Eric Postpischil, that women
need to be taught in the way that is best for them, not in a way that they are
comfortable with, assumes that "best" can be defined universally. Teaching
everyone formal logic may teach people how to write more "correct" programs
with fewer bugs, but it won't help anyone write innovative programs. If
creative people are discouraged by the formal, abstract nature of computer
science, it will only be to the detriment of the field in the end.
Eric Florack asks:
> even-handedness amongst the sexes, I question your conclusions.. Do we attempt
> to change laws of chemestry and electricity because of a particular group of
> students' inability to learn the laws as they are? IE: do we attempt to change
> reality to aid some people's ability to deal with it effectively? Why, then do
> you conclude that to learn computer logic, one need not learn logic, first? Is
> it simply because of one 'minority' or another's inability to deal with that
progression?
First of all, computer science isn't a science like chemistry, it is an
engineering discipline. There are no "laws" of computer science. And
secondly, if scientists had always blindly obeyed the laws as they knew
them, we wouldn't have things like the theory of relativity, quantum
mechanics, or chaos theory.
Eric goes on to say:
> It is the retreat from the more formal, (and yes, harsher) learning
> environments, the 'massive dose of new ideas' that have placed this country
> into the educational crisis it's in today, where nearly 50% of high school
> students cannot read effectively. In the 'marginalized groups' as you put it,
> these percentages are even higher... we expect less of them, so they produce
> less. What you suggest is more of the same.
I disagree completely. Educational techniques have changed very little
in the past century while the world has changed considerably. The
educational crisis is the result of this disparity. Kids don't feel like
their teachers are teaching them anything worth learning, so they don't
learn. Until education is made relevant to kids' lives, the crisis
won't go away. 'Marginalized groups' suffer the most from this problem.
Until education is truly multicultural, these groups will continue
to be marginal. When kids get the message that they are not valued,
they are going to act accordingly.
In the same way, most women are going to avoid computer science until the
computer world begins to value their style of thinking and the contribution
that they could make. And some women in the field will continue to feel
isolated by their difference.
Paula M. Ferguson, Lewis, Trachtenberg & Associates (LTA) +1 617 225 0366
Formalism vs. Experimentation (RISKS-11.86 [,87,88])
Mary Shafer <shafer@skipper.dfrf.nasa.gov>
Thu, 13 Jun 91 12:31:58 PDT
Based on the co-ops and young engineers/programmers that I've worked with, the current methods of teaching programming don't work, whether based on formalism or problem solving philosophies. Being able to write little programs, no matter how elegantly, is no introduction to reality, which seems to consist most frequently of modifying sections of existing (and frequently ugly) code. Debugging is also a topic that should be dealt with in more depth. Mary Shafer ames!skipper.dfrf.nasa.gov!shafer NASA Ames Dryden Flight Research Facility, Edwards, CA
re: Formalism, new twists
Leslie DeGroff <DEGROFF@INTELLICORP.COM>
Wed, 12 Jun 91 17:09:19 PDT
Reading the replies and having watched some previous...What and How to teach computer science discussions, I have a couple bits that might be worthy of attention as we contemplate. Fundamental before we even get to the politics of men/women is the question of what gets taught, why and how is it used... from late 70's till recently there seemed an unfillable demand in America for programmers (and related software skills, software engineers, documenters that understood software, analysts...) This void sucked up almost anyone who could and wanted to do this kind of work...spectrum from starting with a single computer course to PHD's of many flavors.... Coming to today, the demand seems to be slackening but not so much so that we can set up the academic training system so that only .1 percent of the mathematically gifted can past... A useful analogy for education and professional life is that of an adjustable filter, besides shaping people it filters. As a filter, some people get rejected, thats how it works, but the adjustability of the academic part of it is loosly coupled to job market requirements. I say loosely coupled because some CS education programs with quite high formal contents are relatively weak on critical job related skills like test design, requirement and user oriented design that are needed to build real world systems. To make an exaggerated example, the formal analysis of a computation problem will not help if the engineer puts in no input checking to insure that the input is a number. (sorry to say, I've seen that bad, defended as performance requirements) Similar loose coupling is common in all engineering fields, there are risks in at least two directions, the curiculum gets so formal and remote as to not be useful to the profession or it gets watered down and too many graduates are release unable to perform the work. This and many other curriculum and accreditation discussion are a necessary part of the eternal vigilance of professions and so should be frequently discussed. Personally I think the roots of the argument are such that the solution is that nobody wins... I don't believe that the formalists want or imagine computer science in the US to be 95% mathematics with no computers or that the other side wants no logic or mathematics, they are discussing in an exaggerated way the balance point. Changing directions from whats the arg and why nobody should win, I'd like to pick up the thread about various styles as stereotyped by nationality; there do seem to be important differences in working style fostered by different cultures and education systems and in my experience this is stronger than sexual differences... The hardworking diligent precise asian, the theoretical indian, the hacker american are dangerous stereotypes with some base of observable truth, and out in industry they have strengths and weaknesses, it seems that with in a curriculum for computer science overburdened as it is that there is a need the project management, working as teams foci and this useful set of skills if present in several of the programming language and software engineering courses of a program would make them easier and more attractive to certain personality types with certain slightly different skills than the current approaches. I would not leave this in the realm of man/woman, in the company I work for it's marketing/technical and technical/management/production operations were the problems of approach become crisis.
Re: Formalism versus Experimentation (Brown, RISKS-11.89)
Mart Molle <mart@csri.toronto.edu>
Thu, 13 Jun 91 14:10:23 EDT
>The goal should be to produce as many good programmers as we can; don't
>exclude someone or force them to be less efficient by selecting a single
>method of teaching.
This is the wrong goal! Taken to an extreme, we may as well give typewriters
to monkeys and try to pick out the literary works. It would be a mistake to
try to increase the production of good programmers (or bridge builders, or
Chevys...) by adopting new methods of training if those other methods increase
the risk of producing bad programs (or unsafe bridges, or defective Chevys).
Although I know a number of excellent, self-taught programmers, on the whole I
have found that people with formal training tend to write more reliable and
maintainable programs.
Mart L. Molle
Re: Formalism versus Experimentation (Franston, RISKS-11.89)
Rick Smith <smith@SCTC.COM>
Thu, 13 Jun 91 13:11:20 CDT
>To go back to Geraint Jones' bridge building analogy, some of us produce >bridge building kits. Others, having faith that the kits will assure the >bridges will not fall down, concentrate on the aesthetic or political or >whatever aspects are appropriate. I thought that the point of the bridge-building analogy was that there's no such thing as a "bridge building kit." Sure, you can buy prebuilt trusses and assemble them, but the assembly is supervised or at least reviewed after completion by a civil engineer. The construction of reliable software needs the attention of a professional. You don't guarantee the correctness of your solution just by using a "kit" in the form of some higher level language. In the same vein, using SPSS doesn't guarantee the correctness of one's statistical efforts. The user needs to apply formal techniques to assure the validity of the sample population and that the statistical techniques being used are appropriate for analyzing the sample. Well, actually I do know of a class of things called "bridge building kits" but they are generally sold in toy stores. I think this has an apt analogy with software development, too. The unpracticed eye really can't tell the difference between prototype software that tries to simulate a problem solution and software that really implements a problem solution. Bridge building with Lego blocks can be a complex and even satisfying endeavor, but it's just not the same as building one to carry real traffic. Rick Smith, SCTC, Arden Hills, Minnesota.
Formalism versus Experimentation
Michael L Muth <rzw3484@dcrs.dla.mil>
Thu Jun 13 13:03:27 1991
I have read with interest, and considerable dismay, the recent discussion
generated by Danielle Bernstein's comments on Dijkstra's call for reform
in computer science education. Dismay because most (but not all) of the
postings reflect an underlying assumption that women are innately incapable
of mastering logic and mathematics. It seems that even Bernstein makes
this assumption.
Aw, come on folks! The only reason men seem to out-perform women in these
areas is that we are conditioned to it. The conditioning begins in grade
school. Teachers assume that boys will be better at math than girls.
Girls are dissuaded from pursuing higher math, logic, and technical subjects.
Both teachers and parents are to blame here. Since women still comprise
the larger group of educators, this seems to indicate that women themselves
are doing their part to perpetuate the problem.
My daughter received a pretty fair dose of this conditioning. As a result,
she struggled with math. I embarked on a protracted de-programming effort.
Largely because she is now free of this nonsense, she is on track to take
the Calculus AP exam during her Junior year in High School.
Relaxing computer science curricula will not fix this problem (We would only
be addressing the symptoms). On the other hand, I would not want to rely on
software written by a less rigorously trained programmer. Let's fix the
problem, not the symptoms.
*********
Let me shift to a closely related problem I see (which has also been reflected
in this ongoing discussion). Why do we assume programming has to be some kind
of solitary (lonely?) activity? Why do our schools teach programming as an
INDIVIDUAL activity? (A local university not only does not teach team effort
but FAILS or EXPELS students who work together!)
Failure to teach software design and development (SDD) as a team activity
already costs all of us. Major software projects are usually (and should be)
team projects. But, because team members have been conditioned to solitary
effort, these projects suffer from personality and software integration
problems. Students hear of "ego-less programming" but never practice it. How
much have firms like Lotus, Ashton-Tate, and Microsoft suffered from this
problem? How much of your tax dollar is spent on protracted debugging and
retesting of government projects? As a former government QA specialist for
computer software, I can tell you that the cost to taxpayers is more than it
should be.
Why can't our universities require successful completion of a team programming
class for a CS degree. Graduate students would participate as team and project
leaders while undergraduates would make up the teams. Student grades would be
based upon individual, team and project accomplishments. After a few days
discussion of team programming and possibly some team building exercises, the
instructor would hand the students a specification and stand back. The class
would be expected to develop the software and provide draft documentation.
Mike Muth -- mmuth@dcrs.dla.mil
Re: Formalism vs. Experimentation (RISKS-11.86 [,87,88])
Brinton Cooper <abc@BRL.MIL>
Thu, 13 Jun 91 14:20:24 EDT
The RISKs of this discussion are:
1. that it will degenerate into quibbling over the respective
attributes and capabilities of men and women and
2. that some of our readers will actually begin to believe that
women are more (or less) logical than men and less (or more) effective
in working in groups.
It is incredibly unfortunate that sexist issues ever saw the light of day in
CACM., RISKS, or any other credible forum. We have serious issues confronting
us and need the talents of any men, women, and others who can contribute to the
solutions. Research is inconclusive as to whether (elementary age) boys learn
math better than girls. We certainly have no scientific basis to argue whether
women are more or less effective as computer designers.
I don't know whether we should have more or less rigor in CS education. I
believe, however, that whatever the answer, we must assume that it applies
equally to men and women.
_Brint
Re: Formalism versus Experimentation (RISKS-11.88)
Ed Nilges <egnilges@phoenix.princeton.edu>
13 Jun 91 18:53:33 GMT
Tim Shimeall asks:
>Isn't there a need to differentiate programmers by background and
>ability, particularly in development of life-critical systems?
But a two-tier (or even n-tier) class structure in programming could
be as sexist, classist and racist as excluding out-groups in the first
place. Even more, as people are lured into the field, given sub-
standard training, and then face a lifetime of frustration and
glass ceilings.
Furthermore, differentiation of programming problems into Serious
and Not Serious is a rhetorical trick that conceals as well as
reveals. Business problems are commonly regarded by computer
science students and professors as Not Serious Enough, yet Dijkstra
and others have commented on the difficulty of these problems:
as Dijkstra writes,
"The problems of business administration in general and
data base management in particular are much too difficult
for people that think in IBMerese, compounded with sloppy
English."
Also, software reuse implies that a programmer may be working on
code she thinks not mission-critical, only to have the code be
picked up in a mission-critical system at a later time (is a
compiler not life-critical? what if I use it to compile something
that is life-critical?)
Jean-Francois writes (and I apologize for not being able to spell his name with
proper accents):
>The discussion revolves around straightening the three following inconsistent
>propositions:
>
>1 Abstract logic is necessary to the computer industry
>2 Logic is not compatible with women
Good heavens, nobody is making this claim...sounds like something
Jean-Louis Gassee would say on a bad day. For one thing, it's
a type conflict of the first order.
>Most of them have *at best* a knowledge of conversational english, yet they
>have to access to hard technical literature. Those who are not proficient
>enough or cannot adapt are definitely weeded out. You can find this perfectly
>normal or unacceptable depending on how much you think cultural imperialism is
>relevant to computer education.
Cultural imperialism is VERY relevant. Algol lost out to Fortran in
part because of imperialism: Algol was superior to Fortran but the
United States could not concede that the Europeans had the lead in
programming languages.
But I think you'd concede readily enough that it would be a DISSERVICE to
French people and other non-English speakers to avoid requirements that they
learn English as part of the preparation for a technical career. But this is
exactly what Ms. Bernstein wants CS departments to do for women.
Political Correctness: DON'T PANIC!
Glen Ditchfield <gjditchfield@watmsg.waterloo.edu>
Thu, 13 Jun 91 15:33:46 -0400
I think that many of the people discussing this topic are reacting to other
people's interpretations of Bernstein's ideas, rather than to what the CACM
article of November 1990 actually says. For instance,
Ed Nilges: "Bernstein, according to Frankel, feels that Dijkstra is being
sexist!"
Hal Pomeranz: "It is unfortunate that Bernstein slings the word 'sexist'..."
Michael Tobis: "It is more than 'unfortunate' that the word 'sexist' is
used .... The problem is that the issue is being attacked _on the
grounds_ of its social/political appropriateness ..."
My bet is that if we all went back and read the CACM article, the
discussion would be shorter and calmer, and our Moderator would be happier.
Frenkel discusses Bernstein's ideas in six paragraphs of an eleven page
article. No one ever calls Dijkstra "sexist"; Bernstein believes
that Dijkstra's curriculum would cause disproportionate numbers of women to
drop out, but that is not the same as an accusation of sexism. Bernstein
does not call for the removal of formalism from computer science
curriculums; she just wants an introductory CS course, based on the use of
software packages as problem-solving tools, that would help to get women
hooked early.
Frenkel's interpretation of Bernstein's opinion of Dijkstra's proposal
comes down to two sentences:
Bernstein disagrees with this approach because it would discourage
those who want to "see, tinker, experiment, and interact" with
computers in order to understand principles. And so, she says,
Dijkstra's approach would cause computer science majors to further
dwindle.
To me, "those who want to 'see, tinker, experiment, and interact'" sounds
a lot like "hackers", who are stereotypically male. And note that the last
sentence does not say _women_ CS majors. Given earlier statistics and
later comments in the article, I think she is worried about the total
number of CS majors.
Of course, all of the above is just my reading of the article. Please
read it and form your own opinions.
Glen Ditchfield gjditchfield@violet.uwaterloo.ca Office: DC 2517 x3437
Dept. of Computer Science, U of Waterloo, Waterloo, Ontario, Canada, N2L 3G1
Report problems with the web pages to the maintainer